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Abstract 


This document specifies ROHC (Robust Header Compression) profiles 
that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol, 
User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User 
Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP 
(Encapsulating Security Payload) headers. 


This specification defines a second version of the profiles found in 
RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but 
does not obsolete them. 


The ROHCv2 profiles introduce a number of simplifications to the 
rules and algorithms that govern the behavior of the compression 
endpoints. It also defines robustness mechanisms that may be used by 
a compressor implementation to increase the probability of 
decompression success when packets can be lost and/or reordered on 
the ROHC channel. Finally, the ROHCv2 profiles define their own 
specific set of header formats, using the ROHC formal notation. 
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Les 


Introduction 


The ROHC WG has developed a header compression framework on top of 
which various profiles can be defined for different protocol sets or 
compression requirements. The ROHC framework was first documented in 
[RFC3095], together with profiles for compression of RTP/UDP/IP 
(Real-Time Transport Protocol, User Datagram Protocol, Internet 
Protocol), UDP/IP, IP and ESP/IP (Encapsulating Security Payload) 
headers. Additional profiles for compression of IP headers [RFC3843] 
and UDP-Lite (User Datagram Protocol Lite) headers [RFC4019] were 
later specified to complete the initial set of ROHC profiles. 


This document defines an updated version for each of the above 
mentioned profiles, and the definitions depend on the ROHC framework 
as found in [RFC4995]. The framework is required reading to 
understand the profile definitions, rules, and their role. 


Specifically, this document defines header compression schemes for: 


o RTP/UDP/IP : profile 0x0101 
o UDP/IP : profile 0x0102 
o ESP/IP : profile 0x0103 
o IP : profile 0x0104 
o RTP/UDP-Lite/IP : profile 0x0107 
o UDP-Lite/IP : profile 0x0108 


Each of the profiles above can compress the following type of 
extension headers: 


o AH [RFC4302] 

o GRE [RFC2784] [RFC2890] 

o MINE [RFC2004] 

o IPv6 Destination Options header[RFC2460] 

o IPv6 Hop-by-hop Options header[RFC2460] 

o IPv6 Routing header [RFC2460] 

Terminology 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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This document is consistent with the terminology found in the ROHC 
framework [RFC4995] and in the formal notation for ROHC [RFC4997]. 
In addition, this document uses or defines the following terms: 


Acknowledgment Number 


The Acknowledgment Number identifies what packet is being 
acknowledged in the RoHCv2 feedback element (See Section 6.9). 
The value of this field normally corresponds to the Master 
Sequence Number (MSN) of the header that was last successfully 
decompressed, for the compression context (CID) for which the 
feedback information applies. 


Chaining of Items 


A chain of items groups fields based on similar characteristics. 
ROHCv2 defines chain items for static, dynamic and irregular 


fields. Chaining is achieved by appending an item to the chain 
for each header in its order of appearance in the uncompressed 
packet. Chaining is useful to construct compressed headers from 


an arbitrary number of any of the protocol headers for which a 
ROHCv2 profile defines a compressed format. 


CRC-3 Control Fields Validation 


The CRC-3 control fields validation refers to the validation of 
the control fields. This validation is performed by the 
decompressor when it receives a Compressed (CO) header that 
contains a 3-bit Cyclic Redundancy Check (CRC) calculated over 
control fields. This 3-bit CRC covers controls fields carried in 
the CO header as well as specific control fields in the context. 
In the formal definition of the header formats, this 3-bit CRC is 
labeled "control crc3" and uses the control_crc3_encoding (See 
also Section 6.6.11). 


Delta 


The delta refers to the difference in the absolute value of a 
field between two consecutive packets being processed by the same 
compression endpoint. 


Reordering Depth 


The number of packets by which a packet is received late within 
its sequence due to reordering between the compressor and the 
decompressor, i.e., reordering between packets associated with the 
same context (CID). See the definition of sequentially late 
packet below. 
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ROHCv2 Header Types 


ROHCv2 profiles use two different header types: the Initialization 
and Refresh (IR) header type, and the Compressed (CO) header type. 


Sequentially Early Packet 


A packet that reaches the decompressor before one or several 
packets that were delayed over the channel, where all of the said 
packets belong to the same header-compressed flow and are 
associated to the same compression context (CID). At the time of 
the arrival of a sequentially early packet, the packet (s) delayed 
on the link cannot be differentiated from lost packet (s). 


Sequentially Late Packet 


A packet is late within its sequence if it reaches the 
decompressor after one or several other packets belonging to the 
same CID have been received, although the sequentially late packet 
was sent from the compressor before the other packet (s). How the 
decompressor detects a sequentially late packet is outside the 
scope of this specification, but it can for example use the MSN 


for this purpose. 


Timestamp Stride (ts_stride) 


The timestamp stride (ts_stride) is the expected increase in the 
timestamp value between two RTP packets with consecutive sequence 


numbers. For example, for a media encoding with a sample rate of 
8 kHz producing one frame every 20 ms, the RTP timestamp will 
typically increase by n * 160 (= 8000 * 0.02), for some integer n. 


Time Stride (time_stride) 


The time stride (time_stride) is the time interval equivalent to 


one ts_stride, e.g., 20 ms in the example for the RTP timestamp 
increment above. 
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3. Acronyms 


This section lists most acronyms used for reference, in addition to 
those defined in [RFC4995]. 


AH Authentication Header. 

ESP Encapsulating Security Payload. 

GRE Generic Routing Encapsulation. 

FC Full Context state (decompressor). 

IP Internet Protocol. 

LSB Least Significant Bits. 

MINE Minimal Encapsulation in IP. 

MSB Most Significant Bits. 

MSN Master Sequence Number. 

NC No Context state (decompressor). 

OA Optimistic Approach. 

RC Repair Context state (decompressor). 

ROHC Header compression framework (RFC 4995). 

ROHCv2 Set of header compression profiles defined in this document. 

RTP Real-time Transport Protocol. 

SSRC Synchronization source. Field in RTP header. 

CSRC Contributing source. The RTP header contains an optional 
list of contributing sources. 

TC Traffic Class. Field in the IPv6 header. See also TOS. 

TOS Type Of Service. Field in the IPv4 header. See also TC. 

TS RTP Timestamp. 

TTL Time to Live. Field in the IPv4 header. 

UDP User Datagram Protocol. 


UDP-Lite User Datagram Protocol Lite. 
4. Background (Informative) 


This section provides background information on the compression 
profiles defined in this document. The fundamentals of general 
header compression and of the ROHC framework may be found in sections 
3 and 4 of [RFC4995], respectively. The fundamentals of the formal 
notation for ROHC are defined in [RFC4997]. [RFC4224] describes the 
impacts of out-of-order delivery on profiles based on [RFC3095]. 


4.1. Classification of Header Fields 
Section 3.1 of [RFC4995] explains that header compression is possible 
due to the fact that there is much redundancy between field values 
within the headers of a packet, especially between the headers of 


consecutive packets. 


Appendix A lists and classifies in detail all the header fields 
relevant to this document. The appendix concludes with 
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recommendations on how the various fields should be handled by header 
compression algorithms. 

The main conclusion is that most of the header fields can easily be 
compressed away since they never or seldom change. A small number of 


fields however need more sophisticated mechanisms. 


These fields are: 


- IPv4 Identification (16 bits) - IP-ID 

- ESP Sequence Number (32 bits) - ESP SN 

- UDP Checksum (16 bits) - Checksum 
- UDP-Lite Checksum (16 bits) - Checksum 
- UDP-Lite Checksum Coverage (16 bits) - CCov 

- RTP Marker ( 1 bit ) - M-bit 

- RTP Sequence Number (16 bits) - RTP SN 

- RTP Timestamp (32 bits) - TS 


In particular, for RIP, the analysis in Appendix A reveals that the 
values of the RIP Timestamp (TS) field usually have a strong 
correlation to the RTP Sequence Number (SN), which increments by one 
for each packet emitted by an RTP source. The RTP M-bit is expected 
to have the same value most of the time, but it needs to be 
communicated explicitly on occasion. 


For UDP, the Checksum field cannot be inferred or recalculated at the 
receiving end without violating its end-to-end properties, and is 
thus sent as-is when enabled (mandatory with IPv6). The same applies 
to the UDP-Lite Checksum (mandatory with both IPv4 and IPv6), while 
the UDP-Lite Checksum Coverage may in some cases be compressible. 


For IPv4, a similar correlation as that of the RTP TS to the RIP SN 
is often observed between the Identifier field (IP-ID) and the master 
sequence number (MSN) used for compression (e.g., the RIP SN when 
compressing RTP headers). 


4.2. Improvements of ROHCv2 over RFC 3095 Profiles 


The ROHCv2 profiles can achieve compression efficiency and robustness 
that are both at least equivalent to RFC 3095 profiles [RFC3095], 
when used under the same operating conditions. In particular, the 
size and bit layout of the smallest compressed header (i.e., PT-0 
format U/0-0 in RFC 3095, and pt_0_crc3 in ROHCv2) are identical. 


There are a number of differences and improvements between profiles 
defined in this document and their earlier version defined in RFC 
3095. This section provides an overview of some of the most 
significant improvements: 
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Tolerance to reordering 


Profiles defined in RFC 3095 require that the channel between 
compressor and decompressor provide in-order delivery between 


compression endpoints. ROHCv2 profiles, however, can handle 
robustly and efficiently a limited amount of reordering after the 
compression point as part of the compression algorithm itself. In 


addition, this improved support for reordering makes it possible 
for ROHCv2 profiles to handle prelink reordering more efficiently. 


Operational logic 


IP 


IP 


Profiles in RFC 3095 define multiple operational modes, each with 
different updating logic and compressed header formats. ROHCv2 
profiles operate in unidirectional operation until feedback is 
first received for a context (CID), at which point bidirectional 
operation is used, the formats are independent of what operational 
logic is used. 


extension header 


Profiles in RFC 3095 compress IP Extension headers using list 
compression. ROHCv2 profiles instead treat extension headers in 
the same manner as other protocol headers, i.e., using the 
chaining mechanism, it thus assumes that extension headers are not 
added or removed during the lifetime of a context (CID), otherwise 
compression has to be restarted for this flow. 


encapsulation 
Profiles in RFC 3095 can compress at most two levels of IP 


headers. ROHCv2 profiles can compress an arbitrary number of IP 
headers. 


List compression 


ROHCv2 profiles do not support reference-based list compression. 


Robustness and repairs 


ROHCv2 profiles do not define a format for the IR-DYN packet, 
instead, each profile defines a compressed header that can be used 
to perform a more robust context repair using a 7-bit CRC 
verification. This also implies that only the IR header can 
change the association between a CID and the profile it uses. 
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Dis 


Feedback 


ROHCv2 profiles mandate a CRC in the format of the FEEDBACK-2, 
while this is optional in RFC 3095. A different set of feedback 
options is also used in ROHCv2 compared to RFC 3095. 


Operational Characteristics of ROHCv2 Profiles 


Robust header compression can be used over different link 
technologies. Section 4.4 of [RFC4995] lists the operational 
characteristics of the ROHC channel. The ROHCv2 profiles address a 
wide range of applications, and this section summarizes some of the 
operational characteristics that are specific to these profiles. 


Packet length 


ROHCv2 profiles assume that the lower layer indicates the length 
of a compressed packet. ROHCv2 compressed headers do not contain 
length information for the payload. 


Out-of-order delivery between compression endpoints 


The definition of the ROHCv2 profiles places no strict requirement 
on the delivery sequence between the compression endpoints, i.e., 
packets may be received in a different order than the compressor 
has sent them and still have a fair probability of being 
successfully decompressed. 


However, frequent out-of-order delivery and/or significant 
reordering depth will negatively impact the compression 
efficiency. More specifically, if the compressor can operate 
using a proper estimate of the reordering characteristics of the 
path between the compression endpoints, larger headers can be sent 
more often to increase the robustness against decompression 
failures due to out-of-order delivery. (Otherwise, the compression 
efficiency will be impaired from an increase in the frequency of 
decompression failures and recovery attempts. 


Overview of the ROHCv2 Profiles (Informative) 


This section provides an overview of concepts that are important and 
useful to the ROHCv2 profiles. These concepts may be used as 
guidelines for implementations but they are not part of the normative 
definition of the profiles, as these concepts relate to the 
compression efficiency of the protocol without impacting the 
interoperability characteristics of an implementation. 
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5.1. Compressor Concepts 


Header compression can be conceptually characterized as the 

interaction of a compressor with a decompressor state machine, one 
per context. The responsibility of the compressor is to convey the 
information needed to successfully decompress a packet, based on a 
certain confidence regarding the state of the decompressor context. 


This confidence is obtained from the frequency and the type of 
information the compressor sends when updating the decompressor 
context from the optimistic approach (Section 5.1.1), and optionally 
from feedback messages (See Section 6.9), received from the 
decompressor. 


5.1.1. Optimistic Approach 


A compressor always uses the optimistic approach when it performs 
context updates. The compressor normally repeats the same type of 
update until it is fairly confident that the decompressor has 
successfully received the information. If the decompressor 
successfully receives any of the headers containing this update, the 
state will be available for the decompressor to process smaller 
compressed headers. 


If field X in the uncompressed header changes value, the compressor 
uses a header type that contains an encoding of field X until it has 
gained confidence that the decompressor has received at least one 
packet containing the new value for X. The compressor normally 
selects a compressed format with the smallest header that can convey 
the changes needed to achieve confidence. 


The number of repetitions that is needed to obtain this confidence is 
normally related to the packet loss and out-of-order delivery 
characteristics of the link where header compression is used; it is 
thus not defined in this document. It is outside the scope of this 
specification and is left to implementors to decide. 


5.1.2. Tradeoff between Robustness to Losses and to Reordering 


The ability of a header compression algorithm to handle sequentially 
late packets is mainly limited by two factors: the interpretation 
interval offset of the sliding window used for lsb encoded fields 
[RFC4997], and the optimistic approach (See Section 5.1.1) for seldom 
changing fields. 
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lsb encoded fields: 


The interpretation interval offset specifies an upper limit for 
the maximum reordering depth, by which is it possible for the 
decompressor to recover the original value of a dynamically 
changing (i.e., sequentially incrementing) field that is encoded 
using a window-based lsb encoding. Its value is typically bound 
to the number of lsb compressed bits in the compressed header 
format, and thus grows with the number of bits transmitted. 
However, the offset and the lsb encoding only provide robustness 
for the field that it compresses, and (implicitly) for other 
sequentially changing fields that are derived from that field. 


This is shown in the figure below: 


<--- interpretation interval (size is 21k) ----> 
|------------------ um nnn nena | 
v_ref-p v_ref v_ref + (27k-1) - p 
Lower Upper 
Bound Bound 
<--- reordering --> <--------- losses --------- > 


where p is the maximum negative delta, corresponding to the 
maximum reordering depth for which the lsb encoding can recover 
the original value of the field; 


where (2%*k-1) - p is the maximum positive delta, corresponding 
to the maximum number of consecutive losses for which the lsb 
encoding can recover the original value of the field; 


where v_ref is the reference value, as defined in the 1sb 
encoding method in [RFC4997]. 


There is thus a tradeoff between the robustness against reordering 
and the robustness against packet losses, with respect to the 
number of MSN bits needed and the distribution of the 
interpretation interval between negative and positive deltas in 
the MSN. 


Seldom changing fields 


The optimistic approach (Section 5.1.1) provides the upper limit 
for the maximum reordering depth for seldom changing fields. 


There is thus a tradeoff between compression efficiency and 
robustness. When only information on the MSN needs to be conveyed to 
the decompressor, the tradeoff relates to the number of compressed 
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MSN bits in the compressed header format. Otherwise, the tradeoff 
relates to the implementation of the optimistic approach. 


In particular, compressor implementations should adjust their 
optimistic approach strategy to match both packet loss and reordering 
characteristics of the link over which header compression is applied. 
For example, the number of repetitions for each update of a non-1sb 
encoded field can be increased. The compressor can ensure that each 
update is repeated until it is reasonably confident that at least one 
packet containing the change has reached the decompressor before the 
first packet sent after this sequence. 


5.1.3. Interactions with the Decompressor Context 


The compressor normally starts compression with the initial 
assumption that the decompressor has no useful information to process 
the new flow, and sends Initialization and Refresh (IR) packets. 


Initially, when sending the first IR packet for a compressed flow, 
the compressor does not expect to receive feedback for that flow, 
until such feedback is first received. At this point, the compressor 
may then assume that the decompressor will continue to send feedback 
in order to repair its context when necessary. The former is 
referred to as unidirectional operation, while the latter is called 
bidirectional operation. 


The compressor can then adjust the compression level (i.e., what 
header format it selects) based on its confidence that the 
decompressor has the necessary information to successfully process 
the compressed headers that it selects. 


In other words, the responsibilities of the compressor are to ensure 
that the decompressor operates with state information that is 
sufficient to successfully decompress the type of compressed 
header (s) it receives, and to allow the decompressor to successfully 
recover that state information as soon as possible otherwise. The 
compressor therefore selects the type of compressed header based on 
the following factors: 


o the outcome of the encoding method applied to each field; 


o the optimistic approach, with respect to the characteristics of 
the channel; 


o the type of operation (unidirectional or bidirectional), and if in 


bidirectional operation, feedback received from the decompressor 
(ACKs, NACKs, STATIC-NACK, and options). 
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Encoding methods normally use previous value(s) from a history of 
packets whose headers it has previously compressed. The optimistic 
approach is meant to ensure that at least one compressed header 
containing the information to update the state for a field is 
received. Finally, feedback indicates what actions the decompressor 
has taken with respect to its assumptions regarding the validity of 
its context (Section 5.2.2); it indicates what type of compressed 
header the decompressor can or cannot decompress. 


The decompressor has the means to detect decompression failures for 
any compressed (CO) header format, using the CRC verification. 
Depending on the frequency and/or on the type of the failure, it 
might send a negative acknowledgement (NACK) or an explicit request 
for a complete context update (STATIC-NACK). However, the 
decompressor does not have the means to identify the cause of the 
failure, and in particular the decompression of what field(s) is 
responsible for the failure. The compressor is thus always 
responsible for determining the most suitable response to a negative 
acknowledgement, using the confidence it has in the state of the 
decompressor context, when selecting the type of compressed header it 
will use when compressing a header. 


5.2. Decompressor Concepts 


The decompressor normally uses the last received and successfully 
validated (IR packets) or verified (CO packets) header as the 
reference for future decompression. 


The decompressor is responsible for verifying the outcome of every 
decompression attempt, to update its context when successful, and 
finally to request context repairs by making coherent usage of 
feedback once it has started using feedback. 


Specifically, the outcome of every decompression attempt is verified 
using the CRC present in the compressed header; the decompressor 
updates the context information when this outcome is successfully 
verified, finally, if the decompressor uses feedback once for a 
compressed flow, then it will continue to do so for as long as the 
corresponding context is associated with the same profile. 


5.2.1. Decompressor State Machine 
The decompressor operation may be represented as a state machine 
defining three states: No Context (NC), Repair Context (RC), and Full 
Context (FC). 


The decompressor starts without a valid context, the NC state. Upon 
receiving an IR packet, the decompressor validates the integrity of 
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its header using the CRC-8 validation. If the IR header is 
successfully validated, the decompressor updates the context and uses 
this header as the reference header, and moves to the FC state. Once 
the decompressor state machine has entered the FC state, it does not 
normally leave; only repeated decompression failures will force the 
decompressor to transit downwards to a lower state. When context 
damage is detected, the decompressor moves to the repair context (RC) 
state, where it stays until it successfully verifies a decompression 
attempt for a compressed header with a 7-bit CRC or until it 
successfully validates an IR header. When static context damage is 
detected, the decompressor moves back to the NC state. 


Below is the state machine for the decompressor. Details of the 
transitions between states and decompression logic are given in the 
sub-sections following the figure. 


CRC-8 (IR) Validation 


Ho >= >= >= >= >= >= >= >= >= >----+ 
| CRC-8 (IR) | 
| !CRC-8(IR) or CRC-7(CO) or or CRC-7(CO) | 
| PT not allowed CRC-8 (IR) or CRC-3(co) | 
Jh KEE >----- >----- >---4+ +--->---->---+ 
| | | Jan | 
| | v | v | vv 
+ + 42222 KE + 
| No Context (NC) | | Repair Context (RC) | | Full Context (FC) | 
+ AS Hera AA de aaa + 
^ Static Context ^ 1CRC-7 (CO) or ^ Context Damage 
Damage Detected | PT not allowed | Detected 


i | 
| 

| +--<----- <----- <--+ +----<------ <----+ +--<----- <----- <--+ | 
| | 
| | 


Static Context Damage Detected 


+--<----- <----- <----- <----- <----- <----- <----- <----- Ko + 
where: 

CRC-8 (IR) : Successful CRC-8 validation for the IR header. 

ICRC-8 (IR) : Unsuccessful CRC-8 validation for the IR header. 

CRC-7(CO) and/or 

CRC-3 (CO) : Successful CRC verification for the decompression 


of a CO header, based on the number of CRC bits 
carried in the CO header. 


ICRC-7 (CO) : Failure to CRC verify the decompression of a CO 
header carrying a 7-bit CRC. 
PT not allowed : The decompressor has received a packet type (PT) 


for which the decompressor’s current context does 
not provide enough valid state information to 
decompress the packet. 
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Static Context Damage Detected: See definition in Section 5.2.2. 


Context Damage Detected: See definition in Section 5.2.2. 


5.2.1.1. No Context (NC) State 


Initially, while working in the No Context (NC) state, the 
decompressor has not yet successfully validated an IR header. 


Attempting decompression: 


In the NC state, only packets carrying sufficient information on 
the static fields (i.e., IR packets) can be decompressed. 


Upward transition: 


The decompressor can move to the Full Context (FC) state when the 
CRC validation of an 8-bit CRC in an IR header is successful. 


Feedback logic: 


In the NC state, the decompressor should send a STATIC-NACK if a 
packet of a type other than IR is received, or if an IR header has 
failed the CRC-8 validation, subject to the feedback rate 
limitation as described in Section 5.2.3. 


5.2.1.2. Repair Context (RC) State 


In the Repair Context (RC) state, the decompressor has successfully 
decompressed packets for this context, but does not have confidence 
that the entire context is valid. 


Attempting decompression: 


In the RC state, only headers covered by an 8-bit CRC (i.e., IR) 
or CO headers carrying a 7-bit CRC can be decompressed. 


Upward transition: 
The decompressor can move to the Full Context (FC) state when the 


CRC verification succeeds for a CO header carrying a 7-bit CRC or 
when validation of an 8-bit CRC in an IR header succeeds. 


Downward transition: 


The decompressor moves back to the NC state if it assumes static 
context damage. 
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Feedback logic: 


In the RC state, the decompressor should send a STATIC-NACK when 
CRC-8 validation of an IR header fails, or when a CO header 
carrying a 7-bit CRC fails and static context damage is assumed, 
subject to the feedback rate limitation as described in 

Section 5.2.3. If any other packet type is received, the 
decompressor should treat it as a CRC verification failure to 
determine if NACK is to be sent. 


5.2.1.3. Full Context (FC) State 


5 


2 


In the Full Context (FC) state, the decompressor assumes that its 
entire context is valid. 


Attempting decompression: 


In the FC state, decompression can be attempted regardless of the 
type of packet received. 


Downward transition: 


The decompressor moves back to the RC state if it assumes context 
damage. If the decompressor assumes static context damage, it 
moves directly to the NC state. 


Feedback logic: 


In the FC state, the decompressor should send a NACK when CRC-8 
validation or CRC verification of any header type fails and if 
context damage is assumed, or it should send a STATIC-NACK if 
static context damage is assumed; this is subject to the feedback 
rate limitation described in Section 5.2.3. 


.2. Decompressor Context Management 


All header formats carry a CRC and are context updating. A packet 
for which the CRC succeeds updates the reference values of all header 
fields, either explicitly (from the information about a field carried 
within the compressed header) or implicitly (fields inferred from 
other fields). 


The decompressor may assume that some or the entire context is 
invalid, when it fails to validate or to verify one or more headers 
using the CRC. Because the decompressor cannot know the exact 
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reason(s) for a CRC failure or what field caused it, the validity of 
the context hence does not refer to what specific part(s) of the 
context is deemed valid or not. 


Validity of the context rather relates to the detection of a problem 
with the context. The decompressor first assumes that the type of 
information that most likely caused the failure(s) is the state that 
normally changes for each packet, i.e., context damage of the dynamic 
part of the context. Upon repeated decompression failures and 
unsuccessful repairs, the decompressor then assumes that the entire 
context, including the static part, needs to be repaired, i.e., 
static context damage. Failure to validate the 3-bit CRC that 
protects control fields should be treated as a decompression failure 
when the decompressor asserts the validity of its context. 


Context Damage Detection 


The assumption of context damage means that the decompressor will 
not attempt decompression of a CO header that carries only a 3-bit 
CRC, and will only attempt decompression of IR headers or CO 
headers protected by a CRC-7. 


Static Context Damage Detection 


The assumption of static context damage means that the 
decompressor refrains from attempting decompression of any type of 
header other than the IR header. 


How these assumptions are made, i.e., how context damage is detected, 
is open to implementations. It can be based on the residual error 
rate, where a low error rate makes the decompressor assume damage 
more often than on a high rate link. 


The decompressor implements these assumptions by selecting the type 
of compressed header for which it will attempt decompression. In 
other words, validity of the context refers to the ability of a 
decompressor to attempt (or not) decompression of specific packet 
types. 


When ROHCv2 profiles are used over a channel that cannot guarantee 
in-order delivery, the decompressor may refrain from updating its 
context with the content of a sequentially late packet that is 
successfully decompressed. This is to avoid updating the context 
with information that is older than what the decompressor already has 
in its context. 
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5.2.3. Feedback Logic 


ROHCv2 profiles may be used in environments with or without feedback 
capabilities from decompressor to compressor. ROHCv2 however assumes 
that if a ROHC feedback channel is available and if this channel is 
used at least once by the decompressor for a specific context, this 
channel will be used during the entire compression operation for that 
context (i.e., bidirectional operation). 


The ROHC framework defines 3 types of feedback messages: ACKs, NACKs, 
and STATIC-NACKs. The semantics of each message is defined in 
Section 5.2.4.1. of [RFC4995]. What feedback to send is coupled with 
the context management of the decompressor, i.e., with the 
implementation of the context damage detection algorithms as 
described in Section 5.2.2. 


The decompressor should send a NACK when it assumes context damage, 
and it should send a STATIC-NACK when it assumes static context 
damage. The decompressor is not strictly expected to send ACK 
feedback upon successful decompression, other than for the purpose of 
improving compression efficiency. 


When ROHCv2 profiles are used over a channel that cannot guarantee 
in-order delivery, the decompressor may refrain from sending ACK 
feedback for a sequentially late packet that is successfully 
decompressed. 


The decompressor should limit the rate at which it sends feedback, 
for both ACKs and STATIC-NACK/NACKs, and should avoid sending 
unnecessary duplicates of the same type of feedback message that may 
be associated with the same event. 


6.  ROHCv2 Profiles (Normative) 
6.1. Channel Parameters, Segmentation, and Reordering 


The compressor MUST NOT use ROHC segmentation (see Section 5.2.5 of 
[RFC4995]), i.e., the Maximum Reconstructed Reception Unit (MRRU) 
MUST be set to 0, if the configuration of the ROHC channel contains 
at least one ROHCv2 profile in the list of supported profiles (i.e., 
the PROFILES parameter) and if the channel cannot guarantee in-order 
delivery of packets between compression endpoints. 
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6.2. Profile Operation, Per-context 


ROHCv2 profiles operate differently, per context, depending on how 
the decompressor makes use of the feedback channel, if any. Once the 
decompressor uses the feedback channel for a context, it establishes 
the feedback channel for that CID. 


The compressor always starts with the assumption that the 
decompressor will not send feedback when it initializes a new context 
(see also the definition of a new context in Section 5.1.1. of 
[RFC4995], i.e., there is no established feedback channel for the new 
context. At this point, despite the use of the optimistic approach, 
decompression failure is still possible because the decompressor may 
not have received sufficient information to correctly decompress the 
packets; therefore, until the decompressor has established a feedback 
channel, the compressor SHOULD periodically send IR packets. The 
periodicity can be based on timeouts, on the number of compressed 
packets sent for the flow, or any other strategy the implementer 
chooses. 


The reception of either positive feedback (ACKs) or negative feedback 
(NACKs or STATIC-NACKs) from the decompressor establishes the 
feedback channel for the context (CID) for which the feedback was 
received. Once there is an established feedback channel for a 
specific context, the compressor can make use of this feedback to 
estimate the current state of the decompressor. This helps to 
increase the compression efficiency by providing the information 
needed for the compressor to achieve the necessary confidence level. 
when the feedback channel is established, it becomes superfluous for 
the compressor to send periodic refreshes, and instead it can rely 
entirely on the optimistic approach and feedback from the 
decompressor. 


The decompressor MAY send positive feedback (ACKs) to initially 
establish the feedback channel for a particular flow. Either 
positive feedback (ACKs) or negative feedback (NACKs or STATIC-NACKs) 
establishes this channel. Once it has established a feedback channel 
for a CID, the decompressor is REQUIRED to continue sending feedback 
for the lifetime of the context (i.e., until it receives an IR packet 
that associates the CID to a different profile), to send error 
recovery requests and (optionally) acknowledgments of significant 
context updates. 


Compression without an established feedback channel will be less 
efficient, because of the periodic refreshes and the lack of feedback 
to trigger error recovery; there will also be a slightly higher 
probability of loss propagation compared to the case where the 
decompressor uses feedback. 
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6.3. Control Fields 


ROHCv2 defines a number of control fields that are used by the 
decompressor in its interpretation of the header formats received 
from the compressor. The control fields listed in the following 
subsections are defined using the formal notation [RFC4997] in 
Section 6.8.2.4 of this document. 


6.3.1. Master Sequence Number (MSN) 


The Master Sequence Number (MSN) field is either taken from a field 
that already exists in one of the headers of the protocol that the 
profile compresses (e.g., RTP SN), or alternatively it is created at 
the compressor. There is one MSN space per context. 


The MSN field has the following two functions: 


o Differentiating between reference headers when receiving feedback 
data; 


o Inferring the value of incrementing fields (e.g., IPv4 
Identifier). 


There is one MSN field in every ROHCv2 header, i.e., the MSN is 
always present in each header type sent by the compressor. The MSN 
is sent in full in IR headers, while it can be lsb encoded within CO 
header formats. The decompressor always includes LSBs of the MSN in 
the Acknowledgment Number field in feedback (see Section 6.9). The 
compressor can later use this field to infer what packet the 
decompressor is acknowledging. 


For profiles for which the MSN is created by the compressor (i.e., 
0x0102, 0x0104, and 0x0108), the following applies: 


o The compressor only initializes the MSN for a context when that 
context is first created or when the profile associated with a 
context changes; 


o When the MSN is initialized, it is initialized to a random value; 


o The value of the MSN SHOULD be incremented by one for each packet 
that the compressor sends for a specific CID. 


6.3.2. Reordering Ratio 
The control field reorder_ratio specifies how much reordering is 


handled by the lsb encoding of the MSN. This is useful when header 
compression is performed over links with varying reordering 
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characteristics. The reorder_ratio control field provides the means 
for the compressor to adjust the robustness characteristics of the 
lsb encoding method with respect to reordering and consecutive 
losses, as described in Section 5.1.2. 


6.3.3. IP-ID Behavior 


The IP-ID field of the IPv4 header can have different change 
patterns: sequential in network byte order, sequential byte-swapped, 
random or constant (a constant value of zero, although not conformant 
with [RFCO791], has been observed in practice). There is one IP-ID 
behavior control field per IP header. The control field for the 
IP-ID behavior of the innermost IP header determines which set of 
header formats is used. The IP-ID behavior control field is also 
used to determine the contents of the irregular chain item, for each 
IP header. 


ROHCv2 profiles MUST NOT assign a sequential behavior (network byte 
order or byte-swapped) to any IP-ID but the one in the innermost IP 
header when compressing more than one level of IP headers. This is 
because only the IP-ID of the innermost IP header is likely to have a 
sufficiently close correlation with the MSN to compress it as a 
sequentially changing field. Therefore, a compressor MUST assign 
either the constant zero IP-ID or the random IP-ID behavior to 
tunneling headers. 


6.3.4. UDP-Lite Coverage Behavior 


The control field coverage_behavior specifies how the checksum 
coverage field of the UDP-Lite header is compressed with RoHCv2. It 
can indicate one of the following encoding methods: irregular, 
static, or inferred encoding. 


6.3.5. Timestamp Stride 
The ts_stride control field is used in scaled RTP timestamp encoding 


(see Section 6.6.8). It defines the expected increase in the RTP 
timestamp between consecutive RTP sequence numbers. 


6.3.6. Time Stride 


The time_stride control field is used in timer-based compression 
encoding (see Section 6.6.9). When timer-based compression is used, 
time_stride should be set to the expected difference in arrival time 
between consecutive RTP packets. 
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6.3.7.  CRC-3 for Control Fields 


ROHCv2 profiles define a CRC-3 calculated over a number of control 
fields. This 3-bit CRC protecting the control fields is present in 
the header format for the co_common and co_repair header types. 


The decompressor MUST always validate the integrity of the control 
fields covered by this 3-bit CRC when processing a co_common or a 
co_repair compressed header. 


Failure to validate the control fields using this CRC should be 
considered as a decompression failure by the decompressor in the 
algorithm that assesses the validity of the context. However, if the 
decompression attempt can be verified using either the CRC-3 or the 
CRC-7 calculated over the uncompressed header, the decompressor MAY 
still forward the decompressed header to upper layers. This is 
because the protected control fields are not always used to 
decompress the header (i.e., co_common or co_repair) that updates 
their respective value. 


The CRC polynomial and coverage of this CRC-3 is defined in 
Section 6.6.11. 


6.4. Reconstruction and Verification 
Validation of the IR header (8-bit CRC) 


The decompressor MUST always validate the integrity of the IR 
header using the 8-bit CRC carried within the IR header. When the 
header is validated, the decompressor updates the context with the 
information in the IR header. Otherwise, if the IR cannot be 
validated, the context MUST NOT be updated and the IR header MUST 
NOT be delivered to upper layers. 


Verification of CO headers (3-bit CRC or 7-bit CRC) 


The decompressor MUST always verify the decompression of a CO 
header using the CRC carried within the compressed header. When 
the decompression is verified and successful, the decompressor 
updates the context with the information received in the CO 
header; otherwise, if the reconstructed header fails the CRC 
verification, these updates MUST NOT be performed. 


A packet for which the decompression attempt cannot be verified 
using the CRC MUST NOT be delivered to upper layers. 
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Decompressor implementations may attempt corrective or repair 
measures on CO headers prior to performing the above actions, and 
the result of any decompression attempt MUST be verified using the 
CRC. 


6.5. Compressed Header Chains 


Some header types use one or more chains containing sub-header 
information. The function of a chain is to group fields based on 
similar characteristics, such as static, dynamic, or irregular 
fields. 


Chaining is done by appending an item for each header to the chain in 
their order of appearance in the uncompressed packet, starting from 
the fields in the outermost header. 


In the text below, the term <protocol_name> is used to identify 
formal notation names corresponding to different protocol headers. 
The mapping between these is defined in the following table: 


$ === + 0 ESS + + 
| Protocol | protocol_name | 
id + + 
| IPv4 RFC 0791 | ipv4 
| IPv6 RFC 2460 | ipv6 
| UDP RFC 0768 | udp | 
| RTP RFC 3550 | rtp | 
| ESP RFC 4303 | esp | 
UDP-Lite RFC 3828 udp_lite 
| AH RFC 4302 | ah | 
| GRE RFC 2784, RFC 2890 | gre | 
| MINE RFC 2004 | mine | 
| IPv6 Destination Option RFC 2460 | dest_opt | 
IPv6 Hop-by-hop Options RFC 2460 hop_opt 
IPv6 Routing Header RFC 2460 rout_opt 
+ + + 


Static chain: 


The static chain consists of one item for each header of the chain 
of protocol headers that is compressed, starting from the 
outermost IP header. In the formal description of the header 
formats, this static chain item for each header type is labeled 
<protocol_name>_static. The static chain is only used in the IR 
header format. 
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Dynamic chain: 


The dynamic chain consists of one item for each header of the 
chain of protocol headers that is compressed, starting from the 
outermost IP header. In the formal description of the header 
formats, the dynamic chain item for each header type is labeled 
<protocol_name>_dynamic. The dynamic chain is only used in the IR 
and co_repair header formats. 


Irregular chain: 


The structure of the irregular chain is analogous to the structure 
of the static chain. For each compressed header that uses the 
general format of Section 6.8, the irregular chain is appended at 
a specific location in the general format of the compressed 


headers. In the formal description of the header formats, the 
irregular chain item for each header type is a format whose name 
is suffixed by " irregular". The irregular chain is used in all 


CO headers, except for the co_repair format. 


The format of the irregular chain for the innermost IP header 
differs from the format used for the outer IP headers, because the 
innermost IP header is part of the compressed base header. In the 
definition of the header formats using the formal notation, the 
argument "is_innermost", which is passed to the corresponding 
encoding method (ipv4 or ipv6), determines what irregular chain 
items to use. The format of the irregular chain item for the 
outer IP headers is also determined using one flag for TTL/Hop 
Limit and TOS/TC. This flag is defined in the format of some of 
the compressed base headers. 


ROHCv2 profiles compress extension headers as other headers, and thus 
extension headers have a static chain, a dynamic chain, and an 
irregular chain. 


ROHCv2 profiles define chains for all headers that can be compressed, 
i.e., RTP [RFC3550], UDP [RFC0768], ESP [RFC4303], UDP-Lite 
[RFC3828], IPv4 [RFCO791], IPv6 [RFC2460], AH [RFC4302], GRE 
[RFC2784] [RFC2890], MINE [RFC2004], IPv6 Destination Options header 
[RFC2460], IPv6 Hop-by-hop Options header [RFC2460], and IPv6 Routing 
header [RFC2460]. 


6.6. Header Formats and Encoding Methods 
The header formats are defined using the ROHC formal notation. Some 


of the encoding methods used in the header formats are defined in 
[RFC4997], while other methods are defined in this section. 
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6.6.1. baseheader_extension_headers 


The baseheader_extension_headers encoding method skips over all 
fields of the extension headers of the innermost IP header, without 
encoding any of them. Fields in these extension headers are instead 
encoded in the irregular chain. 


This encoding is used in CO headers (see Section 6.8.2). The 
innermost IP header is combined with other header (s) (i.e., UDP, UDP- 
Lite, RTP) to create the compressed base header. In this case, there 


may be a number of extension headers between the IP headers and the 
other headers. 


The base header defines a representation of the extension headers, to 
comply with the syntax of the formal notation; this encoding method 
provides this representation. 


6.6.2. baseheader_outer_headers 


The baseheader_outer_headers encoding method skips over all the 
fields of the extension header (s) that do not belong to the innermost 
IP header, without encoding any of them. Changing fields in outer 
headers are instead handled by the irregular chain. 


This encoding method, similarly to the baseheader_extension_headers 
encoding method above, is necessary to keep the definition of the 
header formats syntactically correct. It describes tunneling IP 
headers and their respective extension headers (i.e., all headers 
located before the innermost IP header) for CO headers (see 

Section 6.8.2). 


6.6.3. inferred udp length 


The decompressor infers the value of the UDP length field as being 
the sum of the UDP header length and the UDP payload length. The 
compressor must therefore ensure that the UDP length field is 
consistent with the length field(s) of preceding subheaders, i.e., 
there must not be any padding after the UDP payload that is covered 
by the IP Length. 


This encoding method is also used for the UDP-Lite Checksum Coverage 
field when it behaves in the same manner as the UDP length field 
(i.e., when the checksum always covers the entire UDP-Lite payload). 


6.6.4. inferred ip v4 header checksum 


This encoding method compresses the header checksum field of the IPv4 
header. This checksum is defined in RFC 791 [RFCO791] as follows: 
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Header Checksum: 16 bits 


A checksum on the header only. Since some header fields change 
(e.g., time to live), this is recomputed and verified at each 
point that the internet header is processed. 


The checksum algorithm is: 


The checksum field is the 16 bit one's complement of the one's 
complement sum of all 16 bit words in the header. For purposes 
of computing the checksum, the value of the checksum field is 
zero. 


As described above, the header checksum protects individual hops from 
processing a corrupted header. As the data that this checksum 
protects is mostly compressed away and is instead taken from state 
stored in the context, this checksum becomes cumulative to the ROHC 
CRC. When using this encoding method, the checksum is recomputed by 
the decompressor. 


The inferred_ip_v4_header_checksum encoding method thus compresses 
the header checksum field of the IPv4 header down to a size of zero 
bits, i.e., no bits are transmitted in compressed headers for this 
field. Using this encoding method, the decompressor infers the value 
of this field using the computation above. 


The compressor MAY use the header checksum to validate the 
correctness of the header before compressing it, to avoid processing 
a corrupted header. 


6.6.5. inferred mine header checksum 


This encoding method compresses the minimal encapsulation header 
checksum. This checksum is defined in RFC 2004 [RFC2004] as follows: 


Header Checksum 


The 16-bit one's complement of the one's complement sum of all 
16-bit words in the minimal forwarding header. For purposes of 
computing the checksum, the value of the checksum field is 0. 
The IP header and IP payload (after the minimal forwarding 
header) are not included in this checksum computation. 


The inferred mine header checksum encoding method compresses the 
minimal encapsulation header checksum down to a size of zero bits, 
i.e., no bits are transmitted in compressed headers for this field. 
Using this encoding method, the decompressor infers the value of this 
field using the above computation. 
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The motivations for inferring this checksum are similar to the ones 
explained above in Section 6.6.4. 


The compressor MAY use the minimal encapsulation header checksum to 
validate the correctness of the header before compressing it, to 
avoid processing a corrupted header. 


6.6.6. inferred ip v4 length 


This encoding method compresses the total length field of the IPv4 
header. The total length field of the IPv4 header is defined in RFC 
791 [RFCO791] as follows: 


Total Length: 16 bits 


Total Length is the length of the datagram, measured in octets, 
including internet header and data. This field allows the 
length of a datagram to be up to 65,535 octets. 


The inferred ip v4 length encoding method compresses the IPv4 header 
checksum down to a size of zero bits, i.e., no bits are transmitted 
in compressed headers for this field. Using this encoding method, 
the decompressor infers the value of this field by counting in octets 
the length of the entire packet after decompression. 


6.6.7. inferred ip v6 length 


This encoding method compresses the payload length field in the IPv6 
header. This length field is defined in RFC 2460 [RFC2460] as 
follows: 


Payload Length: 16-bit unsigned integer 


Length of the IPv6 payload, i.e., the rest of the packet 
following this IPv6 header, in octets. (Note that any 
extension headers present are considered part of the payload, 
i.e., included in the length count.) 


The "inferred ip v6 length" encoding method compresses the payload 
length field of the IPv6 header down to a size of zero bits, i.e., no 
bits are transmitted in compressed headers for this field. Using 
this encoding method, the decompressor infers the value of this field 
by counting in octets the length of the entire packet after 
decompression. 


IPv6 headers using the jumbo payload option of RFC 2675 [RFC2675] 
will not be compressible with this encoding method since the value of 
the payload length field does not match the length of the packet. 
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6.6.8. Scaled RTP Timestamp Compression 


This section provides additional details on encodings used to scale 
the RTP timestamp, as defined in the formal notation in 
Section 6.8.2.4. 


The RIP timestamp (TS) usually increases by a multiple of the RTP 
Sequence Number’s (SN’s) increase and is therefore a suitable 
candidate for scaled encoding. This scaling factor is labeled 
ts_stride in the definition of the profile in the formal notation. 
The compressor sets the scaling factor based on the change in TS with 
respect to the change in the RTP SN. 


The default value of the scaling factor ts_stride is 160, as defined 
in Section 6.8.2.4. To use a different value for ts_stride, the 
compressor explicitly updates the value of ts_stride to the 
decompressor using one of the header formats that can carry this 
information. 


When the compressor uses a scaling factor that is different than the 
default value of ts_stride, it can only use the new scaling factor 
once it has enough confidence that the decompressor has successfully 
calculated the residue (ts_offset) of the scaling function for the 
timestamp. The compressor achieves this by sending unscaled 
timestamp values, to allow the decompressor to establish the residue 
based on the current ts_stride. The compressor MAY send the unscaled 
timestamp in the same compressed header(s) used to establish the 
value of ts_stride. 


Once the compressor has gained enough confidence that both the value 
of the scaling factor and the value of the residue have been 
established in the decompressor, the compressor can start compressing 
packets using the new scaling factor. 


When the compressor detects that the residue (ts_offset) value has 
changed, it MUST NOT select a compressed header format that uses the 
scaled timestamp encoding before it has re-established the residue as 
described above. 


When the value of the timestamp field wraps around, the value of the 
residue of the scaling function is likely to change. When this 
occurs, the compressor re-establishes the new residue value as 
described above. 


If the decompressor receives a compressed header containing scaled 
timestamp bits while the ts_stride equals zero, it MUST NOT deliver 
the packet to upper layers and it SHOULD treat this as a CRC 
verification failure. 
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Whether or not the scaling is applied to the RTP TS field is up to 
the compressor implementation (i.e., the use of scaling is OPTIONAL), 
and is indicated by the tsc_indicator control field. In case scaling 
is applied to the RTP TS field, the value of ts_stride used by the 
compressor is up to the implementation. A value of ts_stride that is 
set to the expected increase in the RTP timestamp between consecutive 
unit increases of the RTP SN will provide the most gain for the 
scaled encoding. (Other values may provide the same gain in some 
situations, but may reduce the gain in others. 


When scaled timestamp encoding is used for header formats that do not 
transmit any lsb-encoded timestamp bits at all, the 
inferred_scaled_field encoding of Section 6.6.10 is used for encoding 
the timestamp. 


6.6.9. timer_based_lsb 


The timer-based compression encoding method, timer_based_lsb, 
compresses a field whose change pattern approximates a linear 
function of the time of day. 


This encoding uses the local clock to obtain an approximation of the 
value that it encodes. The approximated value is then used as a 
reference value together with the num_lsbs_param least-significant 
bits received as the encoded value, where num_lsbs_param represents a 
number of bits that is sufficient to uniquely represent the encoded 
value in the presence of jitter between compression endpoints. 


ts_scaled =:= timer_based_lsb(<time_stride_param>, 
<num_lsbs_param>, <offset_param>) 


The parameters "num_lsbs_param" and "offset param" are the parameters 
to use for the Isb encoding, i.e., the number of least significant 
bits and the interpretation interval offset, respectively. The 
parameter "time_stride_param" represents the context value of the 
control field time_stride. 


This encoding method always uses a scaled version of the field it 
compresses. 


The value of the field is decoded by calculating an approximation of 
the scaled value, using: 


tsc_ref_advanced = tsc_ref + (a_n - a_ref) / time_stride. 
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where: 


- tsc_ref is a reference value of the scaled representation 
of the field. 
- a_n is the arrival time associated with the value to decode. 
- a_ref is the arrival time associated with the reference header. 
- tsc_ref_advanced is an approximation of the scaled value 
of the field. 


The lsb encoding is then applied using the num_lsbs_param bits 
received in the compressed header and the tsc ref advanced as 
"ref value" (as per Section 4.11.5 of [RFC4997]). 


Appendix B.3 provides an example of how the compressor can calculate 
jitter. 


The control field time stride controls whether or not the 
timer based Lab method is used in the CO header. The decompressor 
SHOULD send the CLOCK RESOLUTION option with a zero value, if: 


o it receives a non-zero time stride value, and 


o it has not previously sent a CLOCK RESOLUTION feedback with a non- 
zero value. 


This is to allow compression to recover from the case where a 
compressor erroneously activates timer-based compression. 


The support and usage of timer-based compression is OPTIONAL for both 
the compressor and the decompressor; the compressor is not required 
to set the time stride control field to a non-zero value when it has 
received a non-zero value for the CLOCK RESOLUTION option. 


6.6.10. inferred scaled field 


The inferred scaled field encoding method encodes a field that is 
defined as changing in relation to the MSN, and for which the 
increase with respect to the MSN can be scaled by some scaling 
factor. This encoding method is used in compressed header formats 
that do not contain any bits for the scaled field. In this case, the 
decompressor infers the unscaled value of the scaled field from the 
MSN field. The unscaled value is calculated according to the 
following formula: 


unscaled value = delta msn * stride + reference unscaled value 


where "delta msn" is the difference in MSN between the reference 
value of the MSN in the context and the value of the MSN decompressed 
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from this packet, "reference_unscaled_value" is the value of the 
field being scaled in the context, and "stride" is the scaling value 
for this field. 


For example, when this encoding method is applied to the RTP 
timestamp in the RTP profile, the calculation above becomes: 


timestamp = delta msn ” ts stride + reference timestamp 
6.6.11. control crc3 encoding 


The control crc3 encoding method provides a CRC calculated over a 
number of control fields. The definition of this encoding method is 
the same as for the "crc" encoding method specified in Section 4.11.6 
of [RFC4997], with the difference being that the data covered by the 
CRC is given by a concatenated list of control fields. 


In other words, the definition of the control crc3 encoding method is 
equivalent to the following definition: 


control cre encoding(ctrl data value, ctrl data length) 
{ 
UNCOMPRESSED { 
} 
COMPRESSED { 
control_crc3 =:= 
crc(3, 0x06, 0x07, ctrl data value, ctrl data length) [ 3 ]; 


} 


where the parameter "ctrl_data_value" binds to the concatenated 
values of the following control fields, in the order listed below: 


o reorder_ratio, 2 bits padded with 6 MSB of zeroes 
o ts_stride, 32 bits (only for profiles 0x0101 and 0x0107) 
o time_stride, 32 bits (only for profiles 0x0101 and 0x0107) 


o msn, 16 bits (not applicable for profiles 0x0101, 0x0103, and 
0x0107) 


o coverage behavior, 2 bits padded with 6 MSB of zeroes (only for 
profiles 0x0107 and 0x0108) 
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o ip id behavior, one octet for each IP header in the compressible 
header chain starting from the outermost header. Each octet 
consists of 2 bits padded with 6 MSBs of zeroes. 


The "ctrl data length" binds to the sum of the length of the control 
field(s) that are applicable to the specific profile. 


The decompressor uses the resulting 3-bit CRC to validate the control 
fields that are updated by the co_common and co_repair header 
formats; this CRC cannot be used to verify the outcome of a 
decompression attempt. 


This CRC protects the update of control fields, as the updated values 
are not always used to decompress the header that carries them and 
thus are not protected by the CRC-7 verification. This prevents 
impairments that could occur if the decompression of a co_common or 
of a co_repair succeeds and the decompressor sends positive feedback, 
while for some reason the control fields are incorrectly updated. 


6.6.12. inferred sequential ip id 


This encoding method is used with a sequential IP-ID behavior 
(sequential or sequential byte-swapped) and when there are no coded 
IP-ID bits in the compressed header. In this case, the IP-ID offset 
from the MSN is constant, and the IP-ID increases by the same amount 
as the MSN (similar to the inferred scaled field encoding method). 


The decompressor calculates the value for the IP-ID according to the 
following formula: 


IP-ID = delta msn + reference IP ID value 


where "delta msn" is the difference between the reference value of 
the MSN in the context and the uncompressed value of the MSN 
associated to the compressed header, and where 
"reference IP ID value" is the value of the IP-ID in the context. 
For swapped IP-ID behavior (i.e., when ip id behavior innermost is 
set to IP ID BEHAVIOR SEQUENTIAL SWAPPED), "reference IP ID value" 
and "IP-ID" are byte-swapped with regard to the corresponding fields 
in the context. 


If the IP-ID behavior is random or zero, this encoding method does 
not update any fields. 
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6.6.13. list csrc(cc value) 


This encoding method compresses the list of RTP CSRC identifiers 
using list compression. This encoding establishes a content for the 
different CSRC identifiers (items) and a list describing the order in 
which they appear. 


The compressor passes an argument (cc value) to this encoding method: 
this is the value of the CC field taken from the RTP header. The 
decompressor is required to bind the value of this argument to the 
number of items in the list, which will allow the decompressor to 
correctly reconstruct the CC field. 


6.6.13.1. List Compression 


The CSRC identifiers in the uncompressed packet can be represented as 
an ordered list, whose order and presence are usually constant 


between packets. The generic structure of such a list is as follows: 
+-------- +-------- +-- --+-------- + 
list: | item 1 | item 2 | item n 
+-------- +-------- +-- --+-------- + 


When performing list compression on a CSRC list, each item is the 
uncompressed value of one CSRC identifier. 


The basic principles of list-based compression are the following: 
When initializing the context: 


1) The complete representation of the list of CSRC identifiers is 
transmitted. 


Then, once the context has been initialized: 


2) When the list is unchanged, a compressed header that does not 
contain information about the list can be used. 


3) When the list changes, a compressed list is sent in the compressed 
header, including a representation of its structure and order. 
Previously unknown items are sent uncompressed in the list, while 
previously known items are only represented by an index pointing 
to the item stored in the context. 
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6.6.13.2. Table-based Item Compression 


The table-based item compression compresses individual items sent in 
compressed lists. The compressor assigns a unique identifier, 
"Index", to each item "Item" of a list. 


Compressor Logic 


The compressor conceptually maintains an item table containing all 
items, indexed using "Index". The (Index, Item) pair is sent 
together in compressed lists until the compressor gains enough 
confidence that the decompressor has observed the mapping between 
items and their respective index. Confidence is obtained from the 
reception of an acknowledgment from the decompressor, or by 
sending (Index, Item) pairs using the optimistic approach. (Once 
confidence is obtained, the index alone is sent in compressed 
lists to indicate the presence of the item corresponding to this 
index. 


The compressor MAY reset its item table upon receiving a negative 
acknowledgement. 


The compressor MAY reassign an existing index to a new item by re- 
establishing the mapping using the procedure described above. 


Decompressor Logic 

The decompressor conceptually maintains an item table that 
contains all (Index, Item) pairs received. The item table is 
updated whenever an (Index, Item) pair is received and 
decompression is successful (CRC verification, or CRC-8 
validation). The decompressor retrieves the item from the table 
whenever an Index is received without an accompanying Item. 
If an index is received without an accompanying Item and the 
decompressor does not have any context for this index, the 
decompressor MUST NOT deliver the packet to upper layers. 

6.6.13.3. Encoding of Compressed Lists 


Fach item present in a compressed list is represented by: 


o an Index into the table of items, and a presence bit indicating if 
a compressed representation of the item is present in the list. 


o an item (if the presence bit is set). 
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If the presence bit is not set, the item must already be known by the 
decompressor. 


A compressed list of items uses the following encoding: 


1 2 3 4 5 6 7 


444444444 
| Reserved |PS | m | 
444444444 


| 
/ 


XI. Ty 48.535 E SE | m octets, orm “ 4 bits 


--- --- --- ---/ 


Padding : if PS = O and m is odd 


+---+---+---+---+---+---+---+---+ 


| 
/ 


Item 1, ..., Itemn / variable 


4+---4---4---4---+4---+4---+---+---+ 


Reserved: MUST be set to zero; otherwise, the decompressor MUST 
discard the packet. 


PS: 


m: 


Indicates size of XI fields: 
PS = 0 indicates 4-bit XI fields; 
PS = 1 indicates 8-bit XI fields. 


Number of XI item(s) in the compressed list. Also, the value 


of the cc_value argument of the list_csrc encoding (see 
Section 6.6.13). 


XI 1, ..., XI m: m XI items. Each XI represents one item in the 
list of items of the uncompressed header, in the same order as 
they appear in the uncompressed header. 


The format of an XI item is as follows: 


0 at 2 3 
4---4+---+4+---+4+---+ 
BS = 0% |x| Index | 
+---4+--- a + 


0 kb 2 3 4 5 6 7 
tort ttt ka a Ka 
PS - 1: | X | Reserved | Index 
Klee WE tht a Ka a Ka 


X: Indicates whether the item is present in the list: 
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X = 1 indicates that the item corresponding to the Index is 
sent in the Item 1, ..., Item_n list; 


X = 0 indicates that the item corresponding to the Index is 
not sent. 


Reserved: MUST be set to zero; otherwise, the decompressor MUST 
discard the packet. 


Index: An index into the item table. See Section 6.6.13.4 


when 4-bit XI items are used, the XI items are placed in octets 
in the following manner: 


0i ie S2 o3 E Ve ES oT 
+---+---+---+---+---+---+---+---+ 
| XI_k | XIk + 1 | 
+---+---+---+---+---+---+---+---+ 


Padding: A 4-bit Padding field is present when PS = 0 and the 
number of XIs is odd. The Padding field MUST be set to zero; 
otherwise, the decompressor MUST discard the packet. 


Item 1, ..., item n: Each item corresponds to an XI with X = 1 in 
XI 1, ..., XI m. Each entry in the Item list is the uncompressed 
representation of one CSRC identifier. 


6.6.13.4. Item Table Mappings 


The item table for list compression is limited to 16 different items, 
since the RTP header can only carry at most 15 simultaneous CSRC 
identifiers. The effect of having more than 16 items in the item 
table will only cause a slight overhead to the compressor when items 
are swapped in/out of the item table. 


6.6.13.5. Compressed Lists in Dynamic Chain 


A compressed list that is part of the dynamic chain must have all of 
its list items present, i.e., all X-bits in the XI list MUST be set. 
All items previously established in the item table that are not 
present in the list decompressed from this packet MUST also be 
retained in the decompressor context. 
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6.7. Encoding Methods with External Parameters as Arguments 


A number of encoding methods in Section 6.8.2.4 have one or more 
arguments for which the derivation of the parameter’s value is 
outside the scope of the ROHC-FN [RFC4997] specification of the 
header formats. 


The following is a list of encoding methods with external parameters 
as arguments, from Section 6.8.2.4: 


o udp(profile_value, reorder_ratio_value) 


o udp_lite (profile_value, reorder_ratio_value, 
coverage_behavior_value) 


o esp(profile_value, reorder_ratio_value) 


o rtp(profile_value, ts_stride_value, time_stride_value, 
reorder_ratio_value) 


o ipv4(profile value, is_innermost, outer ip flag, 
ip id behavior value, reorder ratio value)) 


o ipvb(profile value, is innermost, outer ip flag, 
reorder ratio value)) 


o iponly baseheader (profile value, outer ip flag, 
ip id behavior value, reorder ratio value) 


o dp. baseheader (profile value, outer ip flag, ip id behavior value, 
reorder ratio value) 


o udplite baseheader (profile value, outer ip flag, 
ip id behavior value, reorder ratio value) 


o esp baseheader (profile value, outer ip flag, ip id behavior value, 
reorder ratio value) 


o rtp_baseheader (profile value, ts stride value, time stride value, 
outer ip flag, ip id behavior value, reorder ratio value) 


o udplite rtp baseheader (profile value, ts stride value, 
time stride value, outer ip flag, ip id behavior value, 
reorder ratio value, coverage behavior value) 


The following applies for all parameters listed below: At the 


compressor, the value of the parameter is set according to the 
recommendations for each parameter. At the decompressor, the value 
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of the parameter is set to undefined and will get bound by encoding 
methods, except where otherwise noted. 


The following is a list of external arguments with their respective 
definition: 


o profile value: 


Set to the 16-bit number that identifies the profile used to 
compress this packet. When processing the static chain at the 
decompressor, this parameter is set to the value of the profile 
field in the IR header (see Section 6.8.1). 


o “reorder ratio value: 


Set to a 2-bit integer value, using one of the constants whose 
name begins with the prefix REORDERING and as defined in 
Section 6.8.2.4. 


| id behavior value: 


Set to a 2-bit integer value, using one of the constants whose 
name begins with the prefix IP ID BEHAVIOR and as defined in 
Section 6.8.2.4. 


o coverage behavior value: 


Set to a 2-bit integer value, using one of the constants whose 
name begins with the prefix UDP LITE COVERAGE and as defined 
in Section 6.8.2.4. 


o outer ip flag: 


This parameter is set to 1 if at least one of the TOS/TC or 
TTL/Hop Limit fields in outer IP headers has changed compared 
to their reference values in the context; otherwise, it is set 
to 0. This flag may only be set to 1 for the "co_common" 
header format in the different profiles. 


o is innermost: 


This boolean flag is set to 1 when processing the innermost of 
the compressible IP headers; otherwise, it is set to 0. 
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o ts stride value 


The value of this parameter should be set to the expected 
increase in the RTP Timestamp between consecutive RTP sequence 
numbers. The value selected is implementation-specific. See 
also Section 6.6.8. 


o time stride value 


The value of this parameter should be set to the expected 
inter-arrival time between consecutive packets for the flow. 
The value selected is implementation-specific. This parameter 
MUST be set to zero, unless the compressor has received a 
feedback message with the CLOCK RESOLUTION option set to a non- 
zero value. See also Section 6.6.9. 


6.8. Header Formats 


ROHCv2 profiles use two different header types: the Initialization 
and Refresh (IR) header type, and the Compressed header type (CO). 


The CO header type defines a number of header formats: there are two 
sets of base header formats, with a few additional formats that are 
common to both sets. 


6.831: 


Initialization and Refresh Header Format (IR) 


The IR header format uses the structure of the ROHC IR header as 
defined in Section 5.2.2.1 of [RFC4995]. 


Header type: IR 


This header format communicates the static part and the dynamic 
part of the context. 
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6. 


8 


The ROHCv2 IR header has the following format: 


ZN 


0 1: 2 3 4 5 6 7 


: Add-CID octet : if for small CIDs and (CID != 0) 
+---4+---+--- 4-4 4-44 + 

| 1 1 1 1 1 1 0o 1 | IR type octet 
+---4---+---4+---+---4+---+---+---+ 


/ 0-2 octets of CID / 1-2 octets if for large CIDs 


4+---4---4---+4---+4---+---+---+---+ 


| Profile | 1 octet 
+---+---+---+---+---+---+---+---+ 
| CRC | 1 octet 


+---+---+---+---+---+---+---+---+ 


/ Static chain / variable length 


/ Dynamic chain / variable length 


CRC: 8-bit CRC over the entire IR-header, including any CID fields 
and up until the end of the dynamic chain, using the polynomial 
defined in [RFC4995]. For purposes of computing the CRC, the CRC 
field is zero. 

Static chain: See Section 6.5. 


Dynamic chain: See Section 6.5. 


Compressed Header Formats (CO) 


6.8.2.1. Design Rationale for Compressed Base Headers 


The compressed header formats are defined as two separate sets for 
each profile: one set for the headers where the innermost IP header 
contains a sequential IP-ID (either network byte order or byte- 
swapped), and one set for the headers without sequential IP-ID 
(either random, zero, or no IP-ID). There are also a number of 
common header formats shared between both sets. In the description 


below, the naming convention used for header formats that belong to 


the sequential set is to include "seq" in the name of the format, 


while similarly "rnd" is used for those that belong to the non- 


sequential set. 
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The design of the header formats is derived from the field behavior 
analysis found in Appendix A. 


All of the compressed base headers transmit lsb-encoded MSN bits and 
a CRC. 


The following header formats exist for all profiles defined in this 
document, and are common to both the sequential and the random header 
format sets: 


o co_common: This format can be used to update the context when the 
established change pattern of a dynamic field changes, for any of 
the dynamic fields. However, not all dynamic fields are updated 
by conveying their uncompressed value; some fields can only be 
transmitted using a compressed representation. This format is 
especially useful when a rarely changing field needs to be 
updated. This format contains a set of flags to indicate what 
fields are present in the header, and its size can vary 
accordingly. This format is protected by a 7-bit CRC. It can 
update control fields, and it thus also carries a 3-bit CRC to 
protect those fields. This format is similar in purpose to the 
UOR-2-extension 3 format of [RFC3095]. 


o co_repair: This format can be used to update the context of all 
the dynamic fields by conveying their uncompressed value. This is 
especially useful when context damage is assumed (e.g., from the 
reception of a NACK) and a context repair is performed. This 
format is protected by a 7-bit CRC. It also carries a 3-bit CRC 
over the control fields that it can update. This format is 
similar in purpose to the IR-DYN format of [RFC3095] when 
performing context repairs. 


o pt O crc3: This format conveys only the MSN; it can therefore only 
update the MSN and fields that are derived from the MSN, such as 
IP-ID and the RTP Timestamp (for applicable profiles). It is 
protected by a 3-bit CRC. This format is equivalent to the UO-0 
header format in [RFC3095]. 


o pt_0_crc7: This format has the same properties as pt_0_crc3, but 
is instead protected by a 7-bit CRC and contains a larger amount 
of lsb-encoded MSN bits. This format is useful in environments 
where a high amount of reordering or a high-residual error rate 
can occur. 
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The following header format descriptions apply to profiles 0x0101 and 
0x0107. 


o 


pt 1 rnd: This format can convey changes to the MSN and to the RIP 
Marker bit, and it can update the RTP timestamp using scaled 
timestamp encoding. It is protected by a 3-bit CRC. It is 
similar in purpose to the UO-1 format in [RFC3095]. 


pt 1 seq id: This format can convey changes to the MSN and to the 
IP-ID. It is protected by a 3-bit CRC. It is similar in purpose 
to the UO-1-ID format in [RFC3095]. 


pt 1 seq ts: This format can convey changes to the MSN and to the 
RTP Marker bit, and it can update the RTP Timestamp using scaled 
timestamp encoding. It is protected by a 3-bit CRC. It is 
similar in purpose to the UO-1-TS format in [RFC3095]. 


pt_2_rnd: This format can convey changes to the MSN, to the RTP 
Marker bit, and to the RTP Timestamp. It is protected by a 7-bit 
CRC. It is similar in purpose to the UOR-2 format in [RFC3095]. 


pt_2_seq_id: This format can convey changes to the MSN and to the 
IP-ID. It is protected by a 7-bit CRC. It is similar in purpose 
to the UO-2-ID format in [RFC3095]. 


pt_2_seq_ts: This format can convey changes to the MSN, to the RTP 
Marker bit and it can update the RIP Timestamp using scaled 
timestamp encoding. It is protected by a 7-bit CRC. It is 
similar in purpose to the UO-2-TS format in [RFC3095]. 


pt 2 seg both: This format can convey changes to both the RTP 
Timestamp and the IP-ID, in addition to the MSN and to the Marker 
bit. It is protected by a 7-bit CRC. It is similar in purpose to 
the UOR-2-ID extension 1 format in [RFC3095]. 


The following header format descriptions apply to profiles 0x0102, 
0x0103, 0x0104, and 0x0108. 


o 


pt. 1 seq id: This format can convey changes to the MSN and to the 
IP-ID. It is protected by a 7-bit CRC. It is similar in purpose 
to the UO-1-ID format in [RFC3095]. 


pt. 2 seq id: This format can convey changes to the MSN and to the 
IP-ID. It is protected by a 7-bit CRC. It is similar in purpose 
to the UO-2-ID format in [RFC3095]. 
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6.8.2.2. co_repair Header Format 
The ROHCv2 co_repair header has the following format: 


De, HO Be 
: Add-CID octet : if for small CIDs and CID 1-15 
+---+---+---4+---4+---+---4+---4+---+ 
| 1 1 1 1 0 1 1 | discriminator 
4+---4--- 4-4 AA EE 


/ 0, 1, or 2 octets of CID / 1-2 octets if large CIDs 


4+---+---4---+---4---+---4+---+---+ 
bx] CRC-7 | 
4+---+---4+---+---4---+---4---+---+ 
| r2 CRC-3 | 
+—---+---+---+---+---+---+---+---+ 


/ Dynamic chain / variable length 


rl: MUST be set to zero; otherwise, the decompressor MUST discard 
the packet. 


CRC-7: A 7-bit CRC over the entire uncompressed header, computed 
using the crc7 (data value, data length) encoding method defined 
in Section 6.8.2.4, where data value corresponds to the entire 
uncompressed header chain and where data length corresponds to the 
length of this header chain. 


r2: MUST be set to zero, otherwise, the decompressor MUST discard 
the packet. 


CRC-3: Encoded using the control crc3 encoding method defined in 
Section 6.6.11. 


Dynamic chain: See Section 6.5. 
6.8.2.3. General CO Header Format 
The CO header format communicates irregularities in the packet 
header. All CO formats carry a CRC and can update the context. All 
CO header formats use the general format defined in this section, 


with the exception of the co_repair format, which is defined in 
Section 6.8.2.2. 
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The general format for a compressed header is as follows: 


0 1 2 3 4 5 6 7 


: Add-CID octet : if for small CIDs and CID 1-15 
+---4---4-- 4-4 4-44 + 
| first octet of base header | (with type indication) 


+---+---+---+---+---+---+---+---+ 
/ 0, 1, or 2 octets of CID / 1-2 octets if large CIDs 


+---+---4---4---4---4-- 4-4 + 
/ remainder of base header / variable length 
+---+---+---+---+---+---+---+---+ 


/ Irregular Chain / variable length 


The base header in the figure above is the compressed representation 
of the innermost IP header and other header(s), if any, in the 
uncompressed packet. The base header formats are defined in 

Section 6.8.2.4. In the formal description of the header formats, 
the base header for each profile is labeled 
profile name” baseheader, where profile name” is defined in the 
following table: 


+22 +22 + 
| Profile number | profile_name | 
+22 +22 + 
| 0x0101 | rtp | 
| 0x0102 | udp | 
| 0x0103 | esp | 
0x0104 ip 
0x0107 udplite_rtp 
| 0x0108 | udplite | 
PEGS EE LEA #375 3283555855 + 


6.8.2.4. Header Formats in ROHC-FN 
This section defines the complete set of base header formats for 


ROHCv2 profiles. The base header formats are defined using the ROHC 
Formal Notation [RFC4997]. 
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// NOTE: The irregular, static, and dynamic chains (see Section 6.5) 
// are defined across multiple encoding methods and are embodied 

// in the correspondingly named formats within those encoding 

// methods. In particular, note that the static and dynamic 

// chains ordinarily go together. The uncompressed fields are 

// defined across these two formats combined, rather than in one 

// or the other of them. The irregular chain items are likewise 

// combined with a baseheader format. 


AAA AAA AAA I/II II III III III III III III TIT TT 
// Constants 
III III III III III III III III III / 


// IP-ID behavior constants 
IP ID BEHAVIOR SEQUENTIAL = 
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED 
IP_ID_BEHAVIOR_RANDOM 

IP_ID_BEHAVIOR_ZERO = 


LA 


ll 
WNR O 


LA 
LA 


F 


// UDP-lite checksum coverage behavior constants 
UDP_LITE_COVERAGE_INFERRED = 07 

UDP_LITE_COVERAGE_STATIC = 1; 

UDP LITE COVERAGE IRREGULAR = 2; 

// The value 3 is reserved and cannot be used for coverage behavior 


// Variable reordering offset 
REORDERING NONE = 0; 
REORDERING_QUARTER 
REORDERING_HALF 

REORDERING_THREEQUARTERS = 


I; 
2; 
3: 


1 


// Profile names and versions 


PROFILE RTP 0101 = 0x0101; 
PROFILE UDP 0102 = 0x0102; 
PROFILE ESP 0103 = 0x0103; 
PROFILE IP 0104 = 0x0104; 


PROFILE_RTP_0107 = 0x0107; // with UDP-LITE 
PROFILE UDPLITE 0108 = 0x0108; // Without RTP 


// Default values for RTP timestamp encoding 
TS STRIDE DEFAULT = 160; 
TIME_STRIDE_DEFAULT 0; 


III II 1111111 III III TT 
// Global control fields 
III 111111111 III II 1 / / 


CONTROL { 
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profile [ 16 ]; 
msn [ 16 1; 
reorder_ratio [ Is 
// ip id fields are for innermost IP header only 
ip id offset [ 16 ]; 
ip id behavior innermost [ 215 
// The following are only used in RTP-based profiles 
ts_stride [ 32 1; 
time_stride [-32 1: 
ts_scaled [ 32 1; 
ts_offset [ 32 1; 
// UDP-lite-based profiles only 

coverage_behavior [ 21; 


} 
AAA AAA AAA AAA AAA AAA AAA AAA TTT TTT TTT TT TTT 


// Encoding methods not specified in FN syntax: 


AAA AAA AAA AAA AAA TTT TTT TTT TTT TT TTT TTT TTT 


baseheader_extension_headers "defined in Section 6.6.1"; 
baseheader_outer_headers "defined in Section 6.6.2"; 
control crc3 encoding "defined in Section 6.6.11", 
inferred ip v4 header checksum "defined in Section 6.6.4", 
inferred ip v4 length "defined in Section 6.6.6", 
inferred ip v6 length "defined in Section 6.6.7", 
inferred mine header checksum "defined in Section 6.6.5", 
inferred scaled field "defined in Section 6.6.10", 
inferred sequential ip id "defined in Section 6.6.12", 
inferred udp length "defined in Section 6.6.3", 
list csrc(cc value) "defined in Section 6.6.13", 
timer based Isb(time stride, k, p) "defined in Section 6.6.9"; 


ARA AAA AA AAA VIII II III III III III III III III AAT 
// General encoding methods 


S11 11111111 1 


static or irreg(flag, width) 
{ 
UNCOMPRESSED { 
field [ width ]; 
} 
COMPRESSED irreg_enc { 
ENFORCE (flag == 1); 
field =:= irregular (width) [ width ]; 
} 


COMPRESSED static_enc { 
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} 


ENFORCE (flag == ); 
field =:= static [ 0 1; 


optional_32 (flag) 


{ 


UNCOMPRESSED { 


} 


item [ 0, 32 ]; 


COMPRESSED present { 


} 


ENFORCE (flag == 1); 
item =:= irregular (32) [ 32 ]; 


COMPRESSED not_present { 


} 


// Send the entire value, 


ENFORCE (flag == 0); 


item =:= compressed_value (0, 0) [0]; 


sdvl_or_static (flag) 


{ 


UNCOMPRESSED { 


} 


field [ 32 ]; 


COMPRESSED present_7bit { 


} 


ENFORCE (flag == 1); 
ENFORCE (field.UVALUE x 2%7); 


ENFORCE (field.CVALUE == field.UVALUE); 
discriminator =:= ’0’ [1]; 
field [ 7 ]; 


COMPRESSED present 14bit { 


} 


ENFORCE (flag == 1); 
ENFORCE (field.UVALUE < 2%14); 


ENFORCE (field.CVALUE == field.UVALUE); 
discriminator =:= ’10’ [-- 2°13 
field Lë JI 


COMPRESSED present 21bit { 


ENFORCE (flag == 1); 
ENFORCE (field.UVALUE x 2421), 
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ENFORCE (field.CVALUE == field.UVALUE); 
discriminator =:= ’110’ [. 307% 
field LS 15 


} 


// Send the entire value, 


} 


COMPRESSED present_28bit { 
ENFORCE (flag == 1); 
ENFORCE (field.UVALUE < 2728), 


ENFORCE (field.CVALUE == field.UVALUE); 
discriminator =:= ’1110’ 4 15 
field [ 28 ]; 


} 


COMPRESSED present_32bit { 


ENFORCE (flag == 1); 

ENFORCE (field.CVALUE == field.UVALUE); 
discriminator =:= ’11111111’ [ 8 ]; 
field L-32 1; 


} 


COMPRESSED not_present { 
ENFORCE (flag == 0); 
field =:= static; 


sdvl_or_default (flag, default_value) 


{ 
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UNCOMPRESSED { 
field [ 32 ]; 
} 


COMPRESSED present_7bit { 
ENFORCE (flag == 1); 
ENFORCE (field.UVALUE < 2%7); 


ENFORCE (field.CVALUE == field.UVALUE); 
discriminator =:= ’0’ [1]; 
field [ 7 ]; 


} 


COMPRESSED present 14bit { 
ENFORCE (flag == 1); 
ENFORCE (field.UVALUE < 2%14); 


ENFORCE (field.CVALUE == field.UVALUE), 
discriminator =:= ’10’ [ 2 ]; 
field [ 14 ]; 


or revert to default value 
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COMPRESSED present 21bit { 


} 


ENFORCE (flag == 1); 
ENFORCE (field.UVALUE < 2421), 


ENFORCE (field.CVALUE == field.UVALUE); 
discriminator =:= ’110’ Es :.3° 1:5 
field [ 21 1; 


COMPRESSED present_28bit ( 


ENFORCE (flag == 1); 
ENFORCE (field.UVALUE < 2428), 


ROHCv2 Profiles 


ENFORCE (field.CVALUE 


discriminator =: 
field 
} 


COMPRESSED present_32bit { 
li 

ENFORCE (field. CVALUE 
(21111111? [ 


ENFORCE (flag == 


discriminator =: 
field 
} 


’ı1110’ 


COMPRESSED not_present { 


ENFORCE (flag == 
field =:= 


} 


1lsb_7_or_31 
{ 
UNCOMPRESSED { 
item [ 32 ]; 
} 


COMPRESSED 1sb 7 { 


discriminator =:= 


item =: 


} 


COMPRESSED 1sb_31 


discriminator =:= 


item =: 
} 


crc3 (data value, 


{ 
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~ 


); 
uncompressed_value (32, 


ror 
lsb (7, 


BAY 


1sb (31 


field.UVALUE); 
[ 41; 
[ 28 ]; 


field.UVALUE); 
8 1; 
[ 32 1; 


CST 304): = 


r ((2%31) 


data_length) 
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UNCOMPRESSED { 
} 
COMPRESSED { 
crc_value =:= crc(3, 0x06, 0x07, data value, data length) [ 3 ]; 


} 


crc7 (data value, data length) 
{ 

UNCOMPRESSED { 

} 


COMPRESSED { 
crc value =:= crc(7, 0x79, Ox7f, data value, data length) [ 7 |: 


// Encoding method for updating a scaled field and its associated 
// control fields. Should be used both when the value is scaled 
// or unscaled in a compressed format. 
// Does not have an uncompressed side. 
field scaling(stride value, scaled value, unscaled value, residue value) 
f 

UNCOMPRESSED { 

// Nothing 
} 


COMPRESSED no_scaling { 
ENFORCE (stride_value == 0), 
ENFORCE (residue_value == unscaled_value); 
ENFORCE (scaled_value == 0); 

} 


COMPRESSED scaling_used { 
ENFORCE (stride_value != 0); 
ENFORCE (residue_value == (unscaled_value % stride_value)); 
ENFORCE (unscaled_value == 
scaled_value * stride_value + residue_value); 


} 
811111111 1 


// IPv6 Destination options header 


ISIS SSS III III I/II I/II 
ip dest opt 


{ 
UNCOMPRESSED { 
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next_header [ 8 ]; 

length [ 8 15 

value [ length.UVALUE * 64 + 48 ]; 
} 
DEFAULT { 

length =:= static; 

next_header =:= static; 

value =:= static; 


} 


COMPRESSED dest_opt_static { 
next header =:= irregular (8) [ 8 ]; 
length =:= irregular(8) [ 8] 


Fr 


} 


COMPRESSED dest_opt_dynamic { 
value =:= 
irregular (length.UVALUE * 64 + 48) [ length.UVALUE * 64 + 48 ]; 
} 


COMPRESSED dest_opt_irregular { 
} 


} 


III III III II 11 1 / 
// IPv6 Hop-by-Hop options header 
III III III 11 1 / 


ip hop opt 
{ 
UNCOMPRESSED { 
next_header [ 8 ]; 
length [ 81; 
value [ length.UVALUE * 64 + 48 ]; 
} 


DEFAULT { 
length =:= static; 
next_header =:= static; 
value =:= static; 


} 


COMPRESSED hop_opt_static { 
next header =:= irregular (8) 
length =:= irregular (8) 

} 


~a~ 
œ œ 
mo 
nen 
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COMPRESSED hop_opt_dynamic { 
value =:= 
irregular (length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 
} 


COMPRESSED hop_opt_irregular { 
} 


} 


III III III III II 11 1 / 
// IPv6 Routing header 
dd dd dd dd dd dd dd dd III dd 


ip rout opt 
{ 
UNCOMPRESSED { 
next_header [ 8 ]; 


length fis 8-13 

value [ length.UVALUE * 64 + 48 ]; 
} 
DEFAULT { 

length =:= static; 

next_header =:= static; 

value =:= static; 


} 


COMPRESSED rout_opt_static { 
next_header = irregular (8) 
length = irregular (8) 
value = = 

irregular (length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 


[ 81; 
[ 81; 


} 


COMPRESSED rout_opt_dynamic { 
} 


COMPRESSED rout_opt_irregular { 
} 
} 


/IIIII III III III II I/II III III TIAA AAAI TIT III TTT 
// GRE Header 
VIVIA AAA I/II III III III III III III III TT 


optional_lsb_7_or_31 (flag) 
{ 


Pelletier & Sandlund Standards Track [Page 53] 


RFC 5225 ROHCv2 Profiles April 2008 


UNCOMPRESSED { 
item [ 0, 32 ]; 
} 


COMPRESSED present { 

ENFORCE (flag == 1); 

item =:= 1sb 7 or 31 [ 8, 32-1; 
} 


COMPRESSED not_present { 
ENFORCE (flag == ); 
item =:= compressed_value (0, 0) [0]; 


} 


optional checksum(flag value) 
f 
UNCOMPRESSED { 
value [ O, 16 ]; 
reservedl [ 0 y 


} 


COMPRESSED cs_present { 
ENFORCE (flag_value == 1); 


value =:= irregular (16) [ 16 ]; 
reservedl =:= uncompressed_value (16, 0) [ 0 1; 
} 
COMPRESSED not_present { 
ENFORCE (flag_value == 0); 
value =:= compressed_value (0, 0) [ 0 ]; 
reservedl =:= compressed_value (0, 0) [ 0 ]; 
} 
} 
gre_proto 
{ 
UNCOMPRESSED { 
protocol [ 16 ]; 
} 
COMPRESSED ether v4 { 
discriminator =:= '0' [ 1 1; 
protocol =:= uncompressed_value(16, 0x0800) [ O ]; 
) 
COMPRESSED ether_v6 ( 
discriminator =:= '1' LOL 1G 
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protocol =:= uncompressed_value (16, 0x86DD) [ O ]; 
} 
} 
gre 
{ 
UNCOMPRESSED { 
c_flag [> ile os 
r_flag =:= uncompressed_value(1, 0) [ 1 1; 
k_flag [ 1]; 
s_flag LE A 1 
reserved0 =:= uncompressed_value(9, 0) [ 9]; 
version =:= uncompressed_value(3, 0) [ 3 1; 
protocol [ 16 ]; 
checksum_and_res [ 0, 32 1; 
key [ 0, 32 1; 
sequence_number [Oy 32:17 
} 
DEFAULT { 
cutlag =:= static; 
k_flag =:= static; 
s_flag =:= static; 
protocol =:= static; 
key =:= static; 
sequence number = static, 
} 
COMPRESSED gre_static { 
ENFORCE ( (c_flag.UVALUE == 1 && checksum_and_res.ULENGTH 32) 
| | checksum_and_res.ULENGTH == 0); 
ENFORCE ( (s_flag.UVALUE == 1 && sequence_number.ULENGTH == 32) 
| | sequence_number.ULENGTH == 0); 
protocol =:= gre_proto KZ: ks 
c flag =:= irregular(1) [1]; 
k_flag =:= irregular(1) KE je 
a flag =:= irregular(1) [Leds 
padding =:= compressed_value(4, 0) [ 4 ]; 
key =:= optional_32(k_flag.UVALUE) [ 0, 32 ]; 


} 


COMPRESSED gre_dynamic { 


checksum_and_res 


optional_checksum 


sequence_number 


} 


(c 


_flag.UVALUE) 
optional_32 (s_flag.UVALUE) 


COMPRESSED gre_irregular { 
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} 


checksum_and_res =:= optional_checksum(c_flag.UVALUE) [ 0, 


sequence number =:= 
optional Lab 7 or 31 (s_flag.UVALUE) [ O, 8, 32 


ANAN AAA AAA AAA AAA AAA AAA AAA dd dd dd d 
// MINE header 
AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA 


mine 


{ 


} 


UNCOMPRESSED { 


next header [ 8 ]; 
s bit [ Lyd; 
res_bits k-77 21% 
checksum [ 16 ], 
orig dest N32 du 
orig src Oy. 32 "es 
} 
DEFAULT { 
next_header =:= static; 
s_bit =:= static; 
res_bits =:= static; 
checksum =:= inferred_mine_header_checksum; 
orig_dest =:= static; 
orig_src =:= static; 


} 


COMPRESSED mine_static { 


} 


next header =:= irregular (8) [ 8 ]; 
s_bit =:= irregular (1) Lo, Le e 
// Reserved bits are included to achieve byte-alignment 
res_bits =:= irregular (7) LL 
orig dest =:= irregular(32) 32215 


orig_src =:= optional 32(s bit.UVALUE) [ 0, 32 ]; 


COMPRESSED mine dynamic ( 


} 


COMPRESSED mine irregular { 


} 


I1 1111111 1 / 
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Authentication Header (AH) 


Wddddddddddddddddddddddddddddddddddddddddddd 


ah 
{ 


} 


UNCOMPRESSED { 


next_header [ 81; 
length E. ik 
res bits =:= uncompressed_value (16, 0) [ 16 1; 
spi [325 15 
sequence number [ 32- ]; 
icv [ length.UVALUE*32-32 ]; 
} 
DEFAULT { 
next_header =:= static; 
length =:= static; 
spi =:= static; 
sequence_number =:= static; 
} 
COMPRESSED ah static { 
next header =:= irregular(8) 8 ], 
length =:= irregular(8) 8 ], 
spi =:= irregular(32) 32 1; 
} 
COMPRESSED ah_dynamic { 
sequence number =:= irregular (32) SF: 
icv =:= 


irregular (length.UVALUE*32-32) 
} 


COMPRESSED ah_irregular { 
sequence number =:= lsb_7_or_31 
icv =:= 
irregular (length. UVALUE* 32-32) 


length.UVALUE* 32-32 ]; 


87 32 13 


length.UVALUE*32-32 ]; 


Wddddddddddddddddddddddddddddddddddddddddddd 


// 


IPv6 Header 


Wddddddddddddddddddddddddddddddddddddddddddd 


fl 
{ 


Pelletier & Sandlund 
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flow label [ 20 ]; 
} 


COMPRESSED fl_zero { 


discriminator =:= '0' [1 17 
flow label = uncompressed_value (20, 0) [ O ]; 
reserved =:= 70000” [4 ]; 


} 


COMPRESSED fl_non_zero { 
discriminator =:= '1' [ 1 
flow_label =:= irregular(20) [ 20 


} 
ipvb(profile value, is_innermost, outer ip flag, reorder_ratio_value) 


f 
UNCOMPRESSED { 


version =:= uncompressed_value (4, 6) [ 4 1; 
tos tc [ 8 1; 
flow_label [ 20 ]; 
payload_length [ 16 ]; 
next_header [ 8 1; 
ttl_hopl [ 8 1; 
src addr [ 128 ]; 
dst_addr [ 128 ]; 
} 
CONTROL { 
ENFORCE (profile == profile_value); 
ENFORCE (reorder_ratio.UVALUE == reorder_ratio_value); 
ENFORCE (innermost_ip.UVALUE == is_innermost); 
innermost ip [ 1 1; 
) 
DEFAULT ( 
tos TC =:= static; 
flow_label =:= static; 
payload_length =:= inferred_ip_v6_length; 
next_header =:= static; 
ttl hopl =:= static; 
src_addr =:= static; 
dst_addr =:= static; 


} 


COMPRESSED ipvb static { 
version_flag Ster ER [ 11; 
innermost_ip =:= irregular(1) [ Le] 
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reserved =:= '0' [ L.T 
flow label =:= fl enc [. 55. 21: Ja 
next header irregular(8) [ 8 ], 
[ 
[ 


src addr irregular (128) 128 ]; 
dst addr =:= irregular(128) 128 ]; 


} 


COMPRESSED ipv6_endpoint_dynamic { 
ENFORCE ( (is_innermost == 1) && 
(profile_value == PROFILE_IP_0104 
tos tc =:= irregular(8) 
ttl hopl =:= irregular(8) 


I; 
[ 
[ 
reserved compressed value(6, 0) [ 
[ 
[ 


| 
une 


reorder_ratio irregular (2) 
msn =:= irregular (16) 


mo 


ON 0100 00 
mes ke Koch ki 
`~ 


1 


Se 


} 


COMPRESSED ipv6_regular_dynamic { 
ENFORCE ( (is_innermost == 0) || 
(profile value != PROFILE IP 0104)), 
tos tc =:= irregular(8) [ 8 1; 
tt1_hopl =:= irregular(8) [ 8 ]; 
) 


COMPRESSED ipv6_outer_irregular { 
ENFORCE (is_innermost == 0); 
EOS: Te = = 
static_or_irreg(outer_ip_flag, 8) [ 0, 8 ]; 
ttl_hopl =:= 
static_or_irreg(outer_ip flag, 8) [ 0, 8 1; 


} 


COMPRESSED ipvb, innermost irregular { 
ENFORCE (is innermost == 1); 
} 


} 


III 111111111111111 1 / 
// IPv4 Header 
AAA AAA AAA AAA AAA AAA AAA dd dd dd d 


ip id enc dyn (behavior) 
f 
UNCOMPRESSED { 
ipid [6-15 
} 
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} 


COMPRESSED ip id seq { 


ENFORCE ( (behavior == IP ID BEHAVIOR SEQUENTIAL) | | 

(behavior == IP ID BEHAVIOR SEQUENTIAL SWAPPED) ); 
ENFORCE (ip_id_offset.UVALUE == ip id.UVALUE - msn.UVALUE) ; 
ip_id =:= irregular(16) [ 16 ]; 


} 


COMPRESSED ip_id_random { 
ENFORCE (behavior == IP ID BEHAVIOR RANDOM), 
ip id =:= irregular (16) [ 16 ]; 

} 


COMPRESSED ip_id_zero { 
ENFORCE (behavior == IP_ID_BEHAVIOR_ZERO); 
ip id =:= uncompressed_value (16, 0) [ 0 ]; 


} 


ip_id_enc_irreg (behavior) 


{ 


} 


UNCOMPRESSED { 
TIPANG Lë 
} 


COMPRESSED ip id seq { 
ENFORCE (behavior == IP ID BEHAVIOR SEQUENTIAL), 
} 


COMPRESSED ip_id_seq_swapped { 
ENFORCE (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED); 
} 


COMPRESSED ip_id_rand { 
ENFORCE (behavior == IP ID BEHAVIOR RANDOM), 
ip id -:- irregular(16) [ 16 ], 

} 


COMPRESSED ip_id_zero { 
ENFORCE (behavior == IP_ID_BEHAVIOR_ZERO); 
ip id =:= uncompressed_value (16, 0) [ 0 ]; 


} 


April 2008 


ipv! (profile value, is_innermost, outer ip flag, ip id behavior value, 


{ 


reorder_ratio_value) 


UNCOMPRESSED { 
version =:= uncompressed_value (4, 4) [ 4]; 
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hdr length =:= uncompressed_value (4, 5) [ 4]; 
tos_tc [ 81; 
length =:= inferred ip v4 length [ 16 1; 
ip_id [ 1:6]: 
Ef =:= uncompressed_value (1, 0) [eS sh she 
df E "ks 
mf =:= uncompressed value(1, 0) EL 
frag offset -:- uncompressed value(13, 0) L 43.15 
ttl hopl [ 8 ]; 
protocol [ 8 ]; 
checksum =:= inferred_ip_v4_header_checksum [ 16 ]; 
src_addr [ 32 ]; 
dst_addr [ 32 1; 
} 
CONTROL { 
ENFORCE (profile == profile_value); 
ENFORCE (reorder_ratio.UVALUE == reorder_ratio_value); 
ENFORCE (innermost_ip.UVALUE == is_innermost); 
ip id behavior outer [ 2 ]; 
innermost ip [ 1 1; 
} 
DEFAULT { 
tos_tc =:= static; 
df =:= static; 
ttl_hopl =:= static; 
protocol =:= static; 
src addr =:= static; 
dst addr =:= static; 
ip_id_behavior_outer =:= static; 
} 
COMPRESSED ipv4_static { 
version_flag Se; 0" DL de 
innermost_ip =:= irregular (1) kk "km 
reserved =:= "000000! Li 262.17 
protocol =:= irregular (8) E 8-15 
src_addr =:= irregular (32) [ 32 ]; 
dst addr =:= irregular(32) 32° 2] 
} 
COMPRESSED ipv4_endpoint_innermost_dynamic { 
ENFORCE ( (is_innermost == 1) && (profile value == PROFILE IP 0104)), 
ENFORCE (ip id behavior innermost.UVALUE == ip id behavior value), 
reserved =:= *000' [ 3 1; 
reorder_ratio =:= irregular (2) BS Er 
df =:= irregular(1) EF £1; 
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ip_id_behavior_innermost =:= irregular (2) L 2:14 
tos_tc =:= irregular (8) [ 8 ]; 
ttl_hopl =:= irregular (8) [ 8 ]; 
ip_id =:= ip_id_enc_dyn(ip_id_behavior_innermost.UVALUE) [ 0, 16 ]; 
msn =:= irregular (16) E Zë Tr 

} 
COMPRESSED ipv4_regular_innermost_dynamic { 
ENFORCE ( (is_innermost == 1) && (profile value != PROFILE_IP_0104)); 
ENFORCE (ip id behavior innermost.UVALUE == ip id behavior value), 
reserved =:= 700000” [:5 12 
df =:= irregular(1) ET AS 
ip id behavior innermost =:= irregular (2) D2? alive 
tos_tc =:= irregular (8) LS 15 
ttl_hopl =:= irregular (8) [ 8 1; 
ip id =:= ip id enc dyn(ip id behavior_innermost.UVALUE) [ 0, 16 ]; 
} 
COMPRESSED ipv4_outer_dynamic { 
ENFORCE (is_innermost == 0), 
ENFORCE (ip_id_behavior_outer.UVALUE == ip_id_behavior_value); 
reserved =:= 700000’ P E "Te 
df =:= irregular(1) Rat 
ip id behavior outer =:= irregular(2) [27T 
tos_tc =:= irregular (8) [ 8 ]; 
ttl_hopl =:= irregular (8) [ 8 ]; 
ip id =:= ip id enc dyn(ip id behavior outer.UVALUE) 05. eebe 
} 
COMPRESSED ipv4_outer_irregular { 
ENFORCE (is_innermost == 0), 
ip_id == 
ip_id_enc_irreg (ip_id_behavior_outer.UVALUE) [ 0, 16 ]; 
tos_tc =:= static_or_irreg(outer_ip_flag, 8) H HS As 
ttl hopl =:= static or irreg(outer ip flag, 8) L Op: 8: lg 
} 
COMPRESSED ipv4_innermost_irregular { 
ENFORCE (is_innermost == 1); 
ip_id =:= 
ip id enc irreg(ip id behavior innermost .UVALUE) [ O, 16 ]; 


} 


ANAN AA ANAN MAMANA NAMAMANA II III I/II I/II III III 
// UDP Header 
VIVIA III III I/II III III III III III III III III III 
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udp (profile_value, reorder_ratio_value) 


{ 


UNCOMPRESSED { 
ENFORCE ( (profile_value == PROFILE RTP 0101) || 
(profile_value == PROFILE_UDP_0102)); 
src_port [ 16 17 
dst port [ 16 ]; 
udp length =:= inferred udp length [ 16 ]; 
checksum [ 16 17 
} 
CONTROL { 
ENFORCE (profile == profile_value); 
ENFORCE (reorder_ratio.UVALUE == reorder_ratio_value); 
checksum_used [ 1 ]; 
} 
DEFAULT { 
src_port =:= static; 
dst_port =:= static; 
checksum_used =:= static; 


} 


COMPRESSED udp_static { 
src_port =:= irregular (16) [ 16 ]; 
dst_port =:= irregular (16) [ 16 ]; 
} 


COMPRESSED udp_endpoint_dynamic { 


ENFORCE (profile_value == PROFILE_UDP_0102); 

ENFORCE (profile == PROFILE_UDP_0102); 

ENFORCE (checksum_used.UVALUE == (checksum.UVALUE != 0)); 
checksum =:= irregular (16) [ 16 ]; 

msn =:= irregular (16) [ 16 ]; 
reserved =:= compressed_value (6, 0) [ 6 |: 


reorder_ratio =:= irregular(2) E 2 J} 


} 


COMPRESSED udp_regular_dynamic { 


ENFORCE (profile value == PROFILE RTP 0101), 
ENFORCE (checksum used.UVALUE == (checksum.UVALUE != 0)); 
checksum =:= irregular (16) [ 16 ]; 


} 


COMPRESSED udp_zero_checksum_irregular { 
ENFORCE (checksum used.UVALUE == 0); 
checksum =:= uncompressed_value (16, 0) [03 13 
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COMPRESSED udp_with_checksum_irregular { 
ENFORCE (checksum_used.UVALUE == 1); 
checksum =:= irregular (16) [ 16 ]; 


} 


ANUMAN INAMIN MAMANA NAMAMANA 44444 
// RTP Header 
NAMAMANA NAMAMANA NAMAMANA dd 4 


Care list dynchain (presence, cc value) 
f 
UNCOMPRESSED { 
csrc list, 


} 


COMPRESSED no_list { 
ENFORCE (cc_value == 0); 
ENFORCE (presence == 0); 
csrc list =:= uncompressed_value (0, 0) [ O]: 


} 
COMPRESSED list_present { 


ENFORCE (presence == 1), 
esrc_list =:= list csrc(cc value) [ VARIABLE ]; 


} 


rtp(profile_value, ts_stride_value, time_stride_value, 
reorder_ratio_value) 


{ 
UNCOMPRESSED { 


ENFORCE ( (profile_value == PROFILE_RTP_0101) || 
(profile_value == PROFILE_RTP_0107)); 
rtp_version =:= uncompressed_value (2, 0) [ 2 1; 
pad_bit leg: 
extension A 
cc [L 4]; 
marker [ 1 1; 
payload_type [ 71; 
sequence_number [ 3:6 -13 
timestamp [ 32 1; 
ssrc [ 32 ]; 
csrc list [ cc.UVALUE * 32 ]; 


} 


CONTROL { 
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ENFORCE (profile 
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profile value), 


( 
ENFORCE (reorder ratio.UVALUE == reorder ratio value), 
ENFORCE (time stride value == time stride.UVALUE), 
ENFORCE (ts stride value == ts stride.UVALUE), 


dummy field =:= 
ts scaled.UVAL 
} 


INITIAL { 
ts_stride 
time_stride 


} 


DEFAULT { 
ENFORCE (msn. UVAL 
pad_bit 
extension 
cc 
marker 
payload_type 
sequence_number 
timestamp 
ssrc 
esrc_list 
ts_stride 
time_stride 
ts_scaled 
ts_offset 


field scaling(ts stride.UVALUE, 


UE, 


UE 


u 
u 


COMPRESSED Pi statie 


SSYC 


} 


timestamp.UVALUE, ts. offset.UVALUE) 


April 2008 


[ 0 ]; 


ncompressed_value (32, TS_STRIDE_DEFAULT) ; 
ncompressed_value (32, TIME STRIDE DEFAULT), 


== sequence number.UVALUE), 


static, 
static, 
static, 
static, 
static, 
static, 
static, 
static, 
static, 
static, 
static, 
static, 
static, 


f 
irregular (32) [ 32 1; 


COMPRESSED rtp dynamic { 


reserved 
reorder_ratio 
list_present 
tss_indicator 
tis_indicator 
pad_bit 
extension 
marker 
payload_type 
sequence_number 
timestamp 
ts_stride 


compressed_value (1, 0) 
irregular (2) 

irregular 
irregular 
irregular 
irregular 
irregular 
irregular 
irregular 
irregular ) 
irregular (32) 


(1 
( 
( 
( 
( 
( 
( 
( 


IKHRERRREN ta 


LA 
LA 
LA 
LA 
LA 
Fr 
Fr 
LA 


F 


Us a RR Koch ech el Kc es 


LA 


l; 


sdvl_or_default (tss indicator.CVALUE, 


TS STRIDE _ DEFAULT) 
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time_stride =:= sdvl_or_default (tis_indicator.CVALUE, 


TIME_STRIDE_DEFAULT) [ VARIABLE ]; 
esrc_list =:= csrc_list_dynchain (list present.CVALUE, 
[ VARIABLE ]; 


cc.UVALUE) 
} 


COMPRESSED rtp_irregular { 
} 
} 


AAA AAA AAA III III I/II III dd 44 
// UDP-Lite Header 
VIVIA AAVV III III III III I/II III I/II III 


checksum_coverage_dynchain (behavior) 
{ 
UNCOMPRESSED { 
checksum_coverage [ 16 ]; 


} 


COMPRESSED inferred_coverage { 
ENFORCE (behavior == UDP_LITE_COVERAGE_INFERRED); 


checksum coverage =:= inferred udp length [ 0 ]; 


} 


COMPRESSED static_coverage { 
ENFORCE (behavior == UDP_LITE_COVERAGE_STATIC); 


checksum_coverage =:= irregular (16) E. 61% 


} 


COMPRESSED irregular_coverage { 
ENFORCE (behavior == UDP LITE COVERAGE IRREGULAR), 


checksum coverage =:= irregular (16) [ 16 ]; 


} 


} 


checksum_coverage_irregular (behavior) 
{ 
UNCOMPRESSED { 
checksum_coverage [ 16 ]; 


} 


COMPRESSED inferred_coverage { 
ENFORCE (behavior == UDP_LITE_COVERAGE_INFERRED); 


checksum coverage =:= inferred udp length [ 0 ]; 


} 


COMPRESSED static_coverage { 
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ENFORCE (behavior == UDP_LITE_COVERAGE_STATIC); 
checksum_coverage =:= static [ O], 


} 


COMPRESSED irregular_coverage { 
ENFORCE (behavior == UDP LITE COVERAGE IRREGULAR), 
checksum coverage =:= irregular (16) 16.1 


} 
} 


udp_lite (profile_value, reorder_ratio_value, coverage_behavior_value) 


{ 
UNCOMPRESSED { 


ENFORCE ( (profile_value == PROFILE_RTP_0107) || 
(profile value == PROFILE_UDPLITE_0108)); 
src_port PULO tz 
dst port [ 16 ]; 
checksum coverage [ 16 ]; 
checksum 14:6: IK 
} 
CONTROL { 
ENFORCE (profile == profile_value); 
ENFORCE (coverage_behavior.UVALUE == coverage_behavior_value); 
ENFORCE (reorder_ratio.UVALUE == reorder_ratio_value); 
} 
DEFAULT { 
src_port =:= static; 
dst_port =:= static; 


coverage_behavior =:= static; 


} 


COMPRESSED udp_lite_static { 
src_port =:= irregular (16) [ 16 1; 
dst_port =:= irregular (16) [ 16 ]; 


} 


COMPRESSED udp_lite_endpoint_dynamic { 


ENFORCE (profile value == PROFILE_UDPLITE_0108); 
reserved =:= compressed_value (4, 0) [ 4]; 
coverage_behavior =:= irregular (2) Es 2: 15 
reorder_ratio = irregular (2) [ 231% 
checksum_coverage =:= 

checksum_coverage_dynchain (coverage_behavior.UVALUE) L Zë tz 
checksum =:= irregular (16) [ 46 155 
msn =:= irregular (16) Le 1% 
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COMPRESSED udp_lite_regular_dynamic { 
ENFORCE (profile_value == PROFILE_RTP_0107); 
coverage_behavior =:= irregular (2) [ 2 
reserved -:- compressed value(6, 0) [ 6 
checksum coverage =:= 
checksum coverage dynchain(coverage behavior.UVALUE) [ 16 1: 
checksum =:= irregular (16) 


} 


COMPRESSED udp_lite_irregular { 
checksum_coverage =:= 
checksum coverage irregular(coverage behavior.UVALUE) [ 0, 16 ]; 
checksum =:= irregular (16) [ 16 ]; 


} 


AAA II III III III III III dd dd 
// ESP Header 
ANAN ANAN AMA III III III III III III I/II III I/II III 


esp (profile_value, reorder_ratio_value) 
{ 
UNCOMPRESSED { 


ENFORCE (profile_value == PROFILE_ESP_0103); 
ENFORCE (msn.UVALUE == sequence_number.UVALUE % 65536); 
spi 321% 
sequence number [ 32 ]; 
} 
CONTROL { 
ENFORCE (profile == profile_value); 
ENFORCE (reorder_ratio.UVALUE == reorder_ratio_value); 
} 
DEFAULT { 
spi =:= static; 
sequence_number =:= static; 


} 
COMPRESSED esp_static { 

spi =:= irregular (32) [32117 
} 


COMPRESSED esp_dynamic { 


sequence number =:= irregular (32) [4532.17 
reserved =:= compressed_value (6, 0) [ 6], 
reorder_ratio =:= irregular (2) E 2 J} 


Pelletier & Sandlund Standards Track [Page 68] 


RFC 5225 ROHCv2 Profiles April 2008 


COMPRESSED esp_irregular { 
} 
} 


AAA (ALALLA dd dd dd dd dd dd dd dd dd dd dd dd dd 
// Encoding methods used in the profiles” CO headers 
AAA AAA AAA III II III II II III III II II II II II III dd 


// Variable reordering offset used for MSN 
men 1sb(k) 
f 
UNCOMPRESSED { 
master [ VARIABLE ], 
} 


COMPRESSED none { 
ENFORCE (reorder_ratio.UVALUE == REORDERING NONE), 
master =:= 1sb(k, 1); 

} 


COMPRESSED quarter { 
ENFORCE (reorder_ratio.UVALUE == REORDERING QUARTER), 
master =:= lsb(k, ((2’k) / 4) - 1); 

} 


COMPRESSED half { 
ENFORCE (reorder ratio.UVALUE == REORDERING HAIF), 
master =:= lsb(k, ((2%*k) / 2) - 1); 

} 


COMPRESSED threequarters { 
ENFORCE (reorder_ratio.UVALUE == REORDERING_THREEQUARTERS) ; 
master =:= 1sb(k, (((2%*k) * 3) / 4) - 1); 


} 


ip_id_lsb (behavior, k) 
{ 
UNCOMPRESSED { 
ipad 1601} 
} 


CONTROL { 
ip_id_nbo [ 16 ]; 
} 


COMPRESSED nbo { 
ENFORCE (behavior == IP_ID_BEHAVIOR_SEQUENTIAL); 
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} 


ENFORCE (ip id offset.UVALUE == ip_id.UVALUE - msn.UVALUE); 
ip id offset =:= 1sb(k, ((2%k) / 4) - 1) [k 1; 
} 


COMPRESSED non nbo { 
ENFORCE (behavior == IP ID BEHAVIOR SEQUENTIAL SWAPPED), 
ENFORCE (ip id nbo.UVALUE == 
(ip id.UVALUE / 256) + (ip id.UVALUE % 256) * 256); 


ENFORCE (ip id nbo.ULENGTH == 16); 
ENFORCE (ip id offset.UVALUE == ip id nbo.UVALUE - msn.UVALUE) ; 
ip id offset =:= 1sb(k, ((2%k) / 4) -1) [k]; 


ip id sequential variable (behavior, indicator) 


{ 


} 


UNCOMPRESSED { 
ipigi 16 Is 
} 


COMPRESSED short { 


ENFORCE ( (behavior == IP_ID_BEHAVIOR_SEQUENTIAL) | | 
(behavior == IP ID BEHAVIOR SEQUENTIAL SWAPPED) ); 

ENFORCE (indicator == 0); 

ip id -:- ip_id_lsb(behavior, 8) [ 8 ]; 


} 


COMPRESSED long { 


ENFORCE ( (behavior == IP_ID_BEHAVIOR_SEQUENTIAL) | | 
(behavior == IP ID BEHAVIOR SEQUENTIAL SWAPPED) ); 

ENFORCE (indicator == 1); 

ENFORCE (ip_id_offset.UVALUE == ip id.UVALUE - msn.UVALUE) ; 

ip id =:= irregular (16) [ 16 ]; 


} 


COMPRESSED not_present { 
ENFORCE ( (behavior == IP ID BEHAVIOR RANDOM) | | 
(behavior == IP_ID_BEHAVIOR_ZERO)); 


dont_fragment (version) 


{ 
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UNCOMPRESSED { 
df [ 0, 1 ]; 
} 


COMPRESSED v4 { 
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ENFORCE (version == 4); 
df =:= irregular (1) [1]; 


} 


COMPRESSED v6 { 
ENFORCE (version == 6); 
unused =:= compressed_value (1, 0) [1]; 


} 


pt_irr_or_static (flag) 
{ 
UNCOMPRESSED { 
payload type [ 7 ]; 
} 


COMPRESSED not_present { 

ENFORCE (flag == 0); 

payload type =:= static [ 0 ]; 
} 


COMPRESSED present { 


ENFORCE (flag == 1); 
reserved =:= compressed value(1, 0) [1]; 
payload type =:= irregular (7) e ek: 
} 
} 
csrc list presence (presence, cc value) 
{ 
UNCOMPRESSED { 
csrc list, 
} 
COMPRESSED no_list { 
ENFORCE (presence == 0); 
csrc list =:= static [ 0 ]; 
} 
COMPRESSED list_present { 
ENFORCE (presence == 1); 
esrc_list =:= list csrc(cc value) [ VARIABLE ]; 


} 


scaled_ts_lsb (time_stride_value, k) 


{ 
UNCOMPRESSED { 
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timestamp [ 32 ]; 
} 


COMPRESSED timerbased { 
ENFORCE (time_stride_value != 0); 
timestamp =:= timer_based_lsb (time_stride_value, k, 
((2%*k) / 2) - 1); 


} 


COMPRESSED regular { 
ENFORCE (time_stride_value == 0); 
timestamp =:= lsb(k, ((2*%k) / 4) - 1); 
} 
} 


// Self-describing variable length encoding with reordering offset 
sdvl1_sn_1sb(field width) 
f 
UNCOMPRESSED { 
field [ field width ], 
} 


COMPRESSED lsb7 { 


discriminator =:= '0' Pl: Zeg 
field =:= msn_lsb (7) po Ja 
} 
COMPRESSED 1sb14 { 
discriminator =:= ’10’ [. 22 
field =:= msn 1sb(14) [ 14 ]; 
} 
COMPRESSED 1sb21 { 
discriminator =:= ’110’ E 23215 
field =:= msn_lsb (21) A 
} 
COMPRESSED 1sb28 { 
discriminator =:= ’1110’ [ 4 1; 
field =:= msn_lsb (28) [ 28 ]; 
} 
COMPRESSED 1sb32 { 
discriminator =:= ’11111111’ [ 8 ]; 
field =:= irregular (field_width) [ field width ]; 
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// Self-describing variable length encoding 


sdvi I1sb(field width) 
{ 
UNCOMPRESSED { 
field [ field_width ]; 
} 


COMPRESSED 1sb7 { 
discriminator =:= '0' 


field =:= 1sb(7, ((2%7) / 4) - 1) 


} 


COMPRESSED 1sb14 { 


discriminator =:= ’10’ 
field =:= 1sb(14, ((2%14) / 4) - 1) 
} 
COMPRESSED 1sb21 { 
discriminator =:= ’110’ 
field =:= 1sb(21, ((2%21) / 4) - 1) 
} 
COMPRESSED 1sb28 { 
discriminator =:= ’1110’ 
field =:= 1sb(28, ((2%28) / 4) - 1) 
} 
COMPRESSED 1sb32 { 
discriminator =:= ’11111111’ 
field =:= irregular (field_width) 
} 
} 
sdvl_scaled_ts_lsb (time_stride) 
{ 
UNCOMPRESSED { 
field [ 32 ]; 
} 
COMPRESSED 1sb7 { 
discriminator =:= ’0’ 
field =:= scaled ts Isb(time stride, 
} 
COMPRESSED 1sb14 { 
discriminator =:= ’10’ 
field =:= scaled ts Isb(time stride, 
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LA 
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COMPRESSED 1sb21 { 
discriminator =:= ’110’ [LS 
field =:= scaled_ts_lsb(time_stride, 21) [ 21 
) 


ang 
KÉ 


KÉ 


COMPRESSED 1sb28 { 
discriminator =:= '1110’ [ 4 
field =:= scaled_ts_lsb(time_stride, 28) [ 28 
} 


e~ 


ang 
` 


COMPRESSED 1sb32 { 
discriminator =:= 11111111” [ 8 
field =:= irregular (32) [ 32 


ang 
KÉ 


KÉ 


} 


variable_scaled_timestamp (tss_flag, tsc flag, ts stride, time stride) 
f 
UNCOMPRESSED { 
scaled value [ 32 ]; 


} 


COMPRESSED present { 


ENFORCE ( (tss_flag == 0) && (tsc flag == 1)); 
ENFORCE (ts_stride != 0); 
scaled_value =:= sdvl_scaled_ts_lsb (time_stride) [ VARIABLE ]; 


} 


COMPRESSED not_present { 
ENFORCE (((tss_flag == 1) && (tsc_flag == 0)) || 
((tss_flag == 0) && (tsc flag == 0))); 


} 


variable_unscaled_timestamp (tss_flag, tsc_flag) 
{ 
UNCOMPRESSED { 
timestamp [ 32 ]; 
} 


COMPRESSED present { 


ENFORCE(((tss flag == 1) && (tsc flag == 0)) | | 
((tss_flag == 0) && (tsc_flag == 0))); 
timestamp =:= sdvl_lsb (32); 


} 


COMPRESSED not_present { 
ENFORCE ( (tss_flag == 0) && (tsc flag == 1)); 
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} 


profile_l_7_flagsl_enc (flag, ip_version) 
{ 
UNCOMPRESSED { 

ip outer indicator [ 1 
ttl hopl indicator [ 1 
tos tc indicator LT 
df [ 0, 1 1; 
ip id behavior [ 2 
reorder_ratio [ 2 


} 


COMPRESSED not_present { 
ENFORCE (flag == y 
ENFORCE (ip_outer_indicator.CVALUE == 0); 
ENFORCE (ttl_hopl_indicator.CVALUE == 0); 
ENFORCE (tos_tc_indicator.CVALUE == 0); 


df =:= static; 
ip_id_behavior =:= static; 
reorder_ratio =:= static; 


} 


COMPRESSED present { 


ENFORCE (flag == 1); 

ip outer indicator =:= irregular (1) EA 
ttl hopl indicator =:= irregular (1) LETS 
tos_tc_indicator =:= irregular (1) [ 1]; 
df =:= dont_fragment (ip_version) fe a NA 
ip_id_behavior =:= irregular (2) [dee 
reorder_ratio =:= irregular (2) [ 2 ]; 


} 


profile 1 flags2 enc(flag) 
{ 

UNCOMPRESSED { 
list_indicator 
pt_indicator 
time_stride_indicator 
pad_bit 
extension 


} 


KÉ 


. ae 


KÉ 


HEHHEHE 
BT E 
` 


`e 


COMPRESSED not_present{ 
ENFORCE (flag == ); 
ENFORCE (list_indicator.UVALUE == 0); 
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ENFORCE (pt. indicator.UVALUE == 0); 

ENFORCE (time stride indicator.UVALUE == 0); 
pad bit =:= static; 

extension =:= static; 


} 


COMPRESSED present { 
ENFORCE (flag == ); 
list_indicator =:= 
pt_indicator =: 


time_stride_indicator 
= irregular (1) 


pad_bit 
extension =:= 
reserved =:= 


} 


irregular (1) 
irregular (1) 


:= irregular (1) 


irregular (1) 
compressed_value(3, 0) 


profile 2 3 4 flags enc(flag, ip version) 


{ 


1 1; 


UNCOMPRESSED ( 
ip outer indicator [ 1 ]; 
df [ O, 
ip id behavior [ 2 


} 


COMPRESSED not_present { 


ENFORCE (flag == 0); 


1; 


ENFORCE (ip_outer_indicator.CVALUE == 0); 


df 
ip id behavior 


} 


COMPRESSED present { 
ENFORCE (flag == 1); 
ip_outer_indicator 
df 
ip id behavior 
reserved 


} 


profile_8_flags_enc (flag, 


{ 

UNCOMPRESSED { 
ip_outer_indicator 
df 
ip_id_behavior 
coverage_behavior 


Pelletier & Sandlund 


& 


static; 
static; 


irregular (1) 


dont_fragment (ip_version) 


irregular (2) 
compressed_value (4, 


p_version) 
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} 


COMPRESSED not_present { 
ENFORCE (flag == ); 
ENFORCE (ip_outer_indicator.CVALUE == 0); 


af =:= static; 
ip_id_behavior =:= static; 
coverage_behavior =:= static; 


} 


COMPRESSED present { 


ENFORCE (flag == 1); 

reserved =:= compressed_value (2, 0) 2215 
ip outer indicator =:= irregular (1) Ek 
df =:= dont fragment (ip version) [1]; 
ip_id_behavior =:= irregular (2) LZ Is 
coverage behavior =:= irregular (2) Els 


} 


profile_7_flags2_enc (flag) 
{ 
UNCOMPRESSED { 


list_indicator Pl. "eg 
pt. indicator Pd Ji 
time stride indicator Dl: RE 
pad bit LL dle 
extension LZ 
[ 2 ] 


coverage_behavior 


KÉ 


} 


COMPRESSED not, present { 
ENFORCE (flag == 0); 
ENFORCE (list_indicator.CVALUE == 0); 
ENFORCE (pt_indicator.CVALUE == 0); 
ENFORCE (time_stride_indicator.CVALUE == 0); 
pad_bit =:= static; 
extension =:= static; 
coverage_behavior =:= static; 


} 


COMPRESSED present { 
ENFORCE (flag == iz 


reserved =:= compressed_value (1, 0) ET I; 
list_indicator =:= irregular (1) RS rad 
pt. indicator =:= irregular(1) Palo NG 
time stride indicator =:= irregular(1) EL Je 
pad bit =:= irregular(1) Palo. 
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extension =:= irregular(1) 
coverage behavior =:= irregular (2) 
} 
} 


ARA III III I III II III III III III III III III AT 
// RTP profile 
LEILI AAA AA AAA AAA AAA TATA TAA ATA AAA AAA 


rtp baseheader (profile value, ts stride value, 
outer ip flag, ip id behavior value, 


reorder ratio value) 


UNCOMPRESSED v4 { 


payload type 
sequence number 
timestamp 

ssrc 


mm 
N H 
m ki 


ENFORCE (msn.UVALUE == sequence number.UVALUE), 
outer headers =:= baseheader outer headers [ 
ip version =:= uncompressed_value (4, 4) [ 
header_length =:= uncompressed_value (4, 5) [ 
tos_tc [ 
length =:= inferred_ip_v4_length [ 
ip_id [ 
BE =:= uncompressed_value (1, 0) [ 
df [ 
mf =:= uncompressed_value (1, 0) [ 
frag_offset =:= uncompressed_value (13, 0) [ 
ttl_hopl [ 
next_header [ 
ip checksum =:= inferred ip v4 header checksum [ 
src addr [ 
dest addr [ 
extension headers =:= baseheader extension headers [ 
src port [ 
dst port [ 
udp length =:= inferred udp length [ 
udp checksum [ 
rtp version =:= uncompressed_value (2, 2) [ 
pad_bit [ 
extension [ 
ce [ 
marker [ 
[ 
[ 
[ 
[ 
[ 


csrc list 


} 


UNCOMPRESSED v6 { 
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time stride value, 


VARIABLE ]; 


16 
32 
32 


VARIABLE ]; 


16 
16 
16 
16 


VARIABLE ]; 
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ENFORCE (ip id behavior innermost.UVALUE == IP ID BEHAVIOR RANDOM), 
ENFORCE (msn.UVALUE == sequence number.UVALUE), 
outer headers =:= baseheader outer headers [ VARIABLE ]; 
ip version =:= uncompressed value(4, 6) [ 4 1; 
tos tc [ 8 1; 
flow_label [ 20 1; 
payload length =:= inferred ip v6 length [> 3165:14 
next header [ 8 1; 
ttl_hopl [ 8 1; 
src addr [ 128 ]; 
dest_addr [ 128 ]; 
extension headers =:= baseheader_extension_headers [ VARIABLE ]; 
src_port [ 16 ]; 
dst_port [ 16 ]; 
udp_length =:= inferred_udp_length Fr do d 
udp, checksum [ 16 ]; 
rtp version =:= uncompressed_value (2, 2) [ 2 Les 
pad bit [ Le 21 
extension [ Je es 
cc [ 4 1; 
marker [ 1 1; 
payload_type [ 71; 
sequence_number E 16-15 
timestamp [ 32 ]; 
ssrc [ 32 1; 
csrc list [ VARIABLE ], 
df =:= uncompressed_value (0,0) [ Ole 
ip id =:= uncompressed value(0,0) [ 0]; 

} 

CONTROL { 
ENFORCE (profile value == PROFILE RTP 0101), 
ENFORCE (profile == profile value), 
ENFORCE (time stride.UVALUE == time stride value), 
ENFORCE (ts stride.UVALUE == ts stride value), 
ENFORCE (reorder ratio.UVALUE == reorder ratio value), 
ENFORCE (ip id behavior innermost.UVALUE == ip id behavior value), 
dummy field -:- field scaling(ts stride.UVALUE, 

ts scaled.UVALUE, timestamp.UVALUE, ts offset.UVALUE) [ O ]; 

} 

INITIAL { 
ts_stride =:= uncompressed_value (32, TS_STRIDE_DEFAULT); 
time_stride =:= uncompressed_value (32, TIME_STRIDE_DEFAULT); 

} 

DEFAULT { 


ENFORCE (outer ip flag == 0), 
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tos_tc =:= static; 
dest_addr =:= static; 

tt1_hopl =:= static; 

src_addr =:= static; 

df =:= static; 
flow_label =:= static; 
next_header =:= static; 

src_port =:= static; 

dst_port =:= static; 

pad_bit =:= static; 
extension =:= static; 

ec =:= static; 

// When marker not present in packets, it is assumed 0 
marker =:= uncompressed_value(1, 0); 
payload_type =:= static; 
sequence_number =:= static; 
timestamp =:= static; 

ssrc =:= static; 

csrc list =:= static; 
ts_stride =:= static; 
time_stride =:= static; 
ts_scaled =:= static; 
ts_offset =:= static; 
reorder_ratio =:= static; 

ip id behavior innermost =:= static; 


} 


// Replacement for UOR-2-ext3 
COMPRESSED co_common { 


ENFORCE (outer ip flag == outer ip indicator.CVALUE), 
discriminator =:= 1117010" [ 8 ]; 
marker =:= irregular(1) [eL AV 
header crce =:= crc7(THIS.UVALUE, THIS.ULENGTH) [7 1; 
flagsl_indicator =:= irregular(1) LA As 
flags2 indicator =:= irregular(1) Ed. Je 
tsc indicator =:= irregular(1) | Ip] DAGAN a 
tss indicator =:= irregular(1) [eek Ute 
ip_id_indicator =:= irregular (1) [ok hs 
control crc3 =:= control crc3 encoding rass 
outer ip indicator : ttl hopl indicator 
tos tc indicator : df : ip id behavior innermost : reorder ratio 
=:= profile 1 7 flagsl enc(flagsl indicator.CVALUE, 
ip version.UVALUE) [ O, 8 1; 
list indicator : pt indicator : tis indicator : pad bit 
extension =:= profile 1 flags2 enc( 
flags2 indicator. CVALUE) [ O, 8 1; 
tos tc =:= static or irreg(tos tc indicator.CVALUE, 8) [ 0, 8]; 


Pelletier & Sandlund Standards Track [Page 80] 


RFC 5225 ROHCv2 Profiles 


ttl hopl =:= static or irreg(ttl hopl indicator.CVALUE, 


ttl hopl.ULENGTH) 
payload type -:- pt irr or static(pt indicator) 
sequence number =:= 

sdv1i sn 1sb (sequence number.ULENGTH) 
ip id -:- ip id sequential variable ( 

ip id behavior innermost.UVALUE, 

ip id indicator.CVALUE) [ 0, 8, 16 |: 


[ 
[ 


April 2008 


0,8]; 
Dro 87 Jr 


LA LA 


[ VARIABLE ]; 


ts_scaled =:= variable_scaled_timestamp (tss_indicator.CVALUE, 


tsc_indicator.CVALUE, ts_stride.UVALUE, 
time stride.UVALUE) 


[ 


timestamp =:= variable unscaled timestamp (tss indicator. 


Lac indicator. CVALUE) 
ts. stride =:= sdv1 or static(tss indicator. CVALUE) 
time stride =:= sdv1i or static(tis indicator. CVALUE) 
csrc list -: 
cc. UVALUE) 


} 


// UO-0 
COMPRESSED pt_0_crc3 { 
discriminator =:= '0' [ 
msn =:= msn_1sb (4) [ 
header crce crc3 (THIS.UVALUE, THIS.ULENGTH) [ 
[ 
[ 


timestamp inferred scaled field 
ipid =:= inferred_sequential_ip_id 


DO OG kä 


} 


// New format, Type 0 with strong CRC and more SN bits 
COMPRESSED pt D crc7 { 
discriminator =:= ’1000’ 
msn =:= msn_lsb(5) 
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) 
timestamp =:= inferred_scaled_field 
ip_id =:= inferred_sequential_ip_id 


o3 aaa 
OONA 


} 


// U0-1 replacement 
COMPRESSED pt 1 rnd ( 
ENFORCE (ts. stride.UVALUE != 0); 
ENFORCE ((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR RANDOM) || 


[ 
[ 
[ 
csrc list presence (list indicator.CVALUE, 


[ 


a Kg Lol Eech Lei 


a is Koch kel Lei 


No ONG an "ae 


KÉ 


No Se Se Ne 


Se 


VARIABLE ]; 
CVALUE, 
VARIABLE ] 
VARIABLE ]; 
VARIABLE ] 


VARIABLE ]; 


(ip id behavior innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 


discriminator =:= ’101’ 

marker := irregular (1) 

msn msn 1sb(4) 

ts. scaled scaled ts 1Isb(time stride.UVALUE, 5) 
header crce =:= crc3(THIS.UVALUE, THIS.ULENGTH) 
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3 ]; 
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} 
// UO-1-ID replacement 
COMPRESSED pt 1 seq id { 
ENFORCE ((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)), 
discriminator =:= ’1001’ [41 
ip id =:= ip id lsb(ip_id behavior_innermost.UVALUE, 4) [ 4 1; 
msn =:= msn_1sb(5) [ 5 1; 
header crc = crc3 (THIS.UVALUE, THIS.ULENGTH) [3% Ti 
timestamp = inferred scaled field bag, Jee 
} 
// U0-1-TS replacement 
COMPRESSED pt 1 seq ts ( 
ENFORCE (ts stride.UVALUE != 0), 
ENFORCE ((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)), 
discriminator =:= ’101’ l: 3:15 
marker =:= irregular(1) BEE 
msn =:= msn_lsb (4) [ 4 ]; 
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ]; 
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [23 Is 
ip_id =:= inferred_sequential_ip_id LJ 
} 
// UOR-2 replacement 
COMPRESSED pt_2_rnd { 
ENFORCE (ts stride.UVALUE != 0); 
ENFORCE ((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR RANDOM) || 
(ip id behavior innermost.UVALUE == IP ID BEHAVIOCR ZERO)), 
discriminator =:= '110' ¡ES He 
msn =:= msn_lsb(7) [ 7 ]; 
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 6) [ 6 ]; 
marker =:= irregular (1) kl Des 
header crce =:= crc7(THIS.UVALUE, THIS.ULENGTH) De 


} 


// UOR-2-ID replacement 
COMPRESSED pt_2_seq_id { 
ENFORCE ( (ip_id_behavior_innermost .UVALUE == 
IP_ID_BEHAVIOR_SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
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IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 


discriminator =:= *11000' KS Is 
msn =:= msn_lsb(7) pk 7 15 
ip id -:- ip id Isb(ip id behavior innermost.UVALUE, 5) [ 5 1; 
header crce =:= crc7(THIS.UVALUE, THIS.ULENGTH) fe do 
timestamp =:= inferred_scaled_field [ 0 ]; 
} 
// UOR-2-ID-ext1 replacement (both TS and IP-ID) 
COMPRESSED pt.2 seg both { 
ENFORCE (ts stride.UVALUE != 0); 
ENFORCE((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)), 
discriminator =:= *11001' KS. 1% 
msn =:= msn_lsb (7) KZ 
ip id -:- ip id Isb(ip id behavior innermost.UVALUE, 5) [ 5 1; 
header crce =:= crc7(THIS.UVALUE, THIS.ULENGTH) KJ 
ts. scaled =:= scaled_ts_lsb (time_stride.UVALUE, 7) Ke 
marker =:= irregular (1) NS Eat: 
} 
// UOR-2-TS replacement 
COMPRESSED pt 2 seq ts { 
ENFORCE (ts stride.UVALUE != 0), 
ENFORCE ((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)), 
discriminator =:= '1101' EA Is 
msn =:= msn_lsb (7) [ 7 ]; 
ts scaled =:= scaled ts Isb(time stride.UVALUE, 5) [5]; 
marker =:= irregular (1) EL 
header crce =:= crc7(THIS.UVALUE, THIS.ULENGTH) PT Te 
ip id =:= inferred sequential ip id Lk 


} 


ARA AAA AAA AAA AAA AAA AAA II AAA 
// UDP profile 
ARA AAA AAA AAA AAA AAA ATA ATA AAA AAA AAT AT 


udp_baseheader (profile value, outer ip flag, ip id behavior value, 
reorder ratio value) 
{ 
UNCOMPRESSED v4 { 
outer headers =:= baseheader outer headers [ VARIABLE ]; 
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ip_version =:= uncompressed_value (4, 4) [ 4]; 
header_length = uncompressed_value (4, 5) [ 41; 
tos_tc [ 81; 
length =:= inferred_ip_v4_length [ 16 ]; 
ip_id [ 16 ]; 

EE =:= uncompressed_value (1, 0) [.. “de Je 
df [ 1 1; 
mf =:= uncompressed_value (1, 0) E. 4-15 
frag_offset =:= uncompressed_value (13, 0) [13 Je 
ttl_hopl [ 8 ]; 
next_header E 821 
ip_checksum =:= inferred_ip_v4_header_checksum ies cyan Ie 
src_addr [ 32 1; 
dest_addr res, Lo 
extension headers := baseheader extension headers [ VARIABLE ]; 
src port [ 16 ], 
dst port [ 16 17 
udp length =:= inferred udp length BLG: Sys 
udp checksum WEE 

} 

UNCOMPRESSED v6 { 
ENFORCE (ip_id_behavior.UVALUE == IP ID BEHAVIOR RANDOM), 
outer headers =:= baseheader outer headers [ VARIABLE ]; 
ip_version =:= uncompressed_value (4, 6) [ 4]; 
tos_tc ku. “Be Ts 
flow label [ 20 ], 
payload length =:= inferred ip v6 length KL 36.5 
next_header [ 81; 
ttl_hopl [ 8 ]; 
src_addr [ 128 ]; 
dest_addr [ 128 ]; 
extension_headers := baseheader extension headers [ VARIABLE ]; 
src port [ 16 17 
dst port [ 16 ]; 
udp length =:= inferred udp length ¡AE Je 
udp_checksum C 1:6: Je 
df =:= uncompressed_value (0,0) [ O. Ja 
ip id =:= uncompressed_value (0,0) Er Gët 

} 

CONTROL { 
ENFORCE (profile_value == PROFILE_UDP_0102); 
ENFORCE (profile == profile_value); 
ENFORCE (reorder_ratio.UVALUE == reorder_ratio_value); 
ENFORCE (ip id behavior innermost.UVALUE == ip id behavior value), 
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DEFAULT { 

ENFORCE (outer ip flag == 0), 
tos tc =:= static; 
dest_addr =:= static; 
ip_version =:= static; 
ttl_hopl =:= static; 
src_addr =:= static; 
df =:= static; 
flow_label =:= static; 
next_header =:= static; 
src_port =:= static; 
dst_port =:= static; 
reorder ratio =:= static; 
ip id behavior innermost =:= static; 


} 


// Replacement for UOR-2-ext3 
COMPRESSED co_common { 


ENFORCE (outer ip flag == outer ip indicator.CVALUE), 
discriminator == 214111010" [ 8 ]: 
ip id indicator =:= irregular(1) kk 
header crce =:= crc7(THIS.UVALUE, THIS.ULENGTH) LR Jo 
flags_indicator =:= irregular(1) [ib] BAG Va 
ttl hopl indicator =:= irregular(1) Poh: I 
tos tc indicator =:= irregular(1) LL We 
reorder ratio =:= irregular (2) [2 As 
control crc3 =:= control crc3 encoding [ 3: JE 
outer_ip_indicator : df : ip_id_behavior_innermost =:= 
profile_2_3_4_flags_enc ( 
flags_indicator.CVALUE, ip_version.UVALUE) L- Or 8? 1% 
tos tc -:- static or irreg(tos tc indicator.CVALUE, 8) [ 0, 8]; 
ttl hopl =:= static or irreg(ttl hopl indicator.CVALUE, 
ttl hopl.ULENGTH) [ 0, 8 1; 
msn =:= msn_lsb (8) E 8- 
ip id =:= ip id sequential variable(ip id behavior innermost.UVALUE, 
ip id indicator. CVALUE) [ 0, 8, 16.1; 
} 
// UO-0 
COMPRESSED pt_0_crc3 { 
discriminator =:= '0' Lk "Is 
msn =:= msn_1sb (4) [4]; 
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 
ip_id =:= inferred_sequential_ip_id REISE 


} 


// New format, Type 0 with strong CRC and more SN bits 
COMPRESSED pt_0_crc7 { 
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discriminator =:= ’100’ es 
msn =:= msn_lsb(6) LS 
header crce =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 
ip_id =:= inferred_sequential_ip_id [ 0 ]; 
} 
// UO-1-ID replacement (PT-1 only used for sequential) 
COMPRESSED pt 1 seq id { 
ENFORCE ((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)), 
discriminator =:= ’101’ l.=3. 15 
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) 13: "je 
msn =:= msn_lsb (6) [ 6 ]; 
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4) [ 4 ]; 
} 
// UOR-2-ID replacement 
COMPRESSED pt_2_seq_id { 
ENFORCE ( (ip_id_behavior_innermost .UVALUE == 
IP_ID_BEHAVIOR_SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)), 
discriminator =:= '110' Ss 
ip id -:- ip id Isb(ip id behavior innermost.UVALUE, 6) [ 6 1; 
header crce =:= crc7(THIS.UVALUE, THIS.ULENGTH) LO Ja 
msn =:= msn 1sb(8) [8 ]; 


} 


ARA III II III III III III III III III I/II III III 
// ESP profile 
LLALLA AAA AAA AAA AAA AAA AA AAA AAA AAA AAA 


esp baseheader (profile value, outer ip flag, ip id behavior value, 
reorder ratio value) 
f 
UNCOMPRESSED v4 { 


ENFORCE (msn.UVALUE == sequence number.UVALUE % 65536); 

outer headers =:= baseheader outer headers [ VARIABLE ]; 
ip_version =:= uncompressed_value (4, 4) L Waals 
header length =:= uncompressed_value (4, 5) [ 41; 
tos_tc [ 81; 
length =:= inferred_ip_v4_length [: Aë: 10 

ip id [ 16 ]; 

rf =:= uncompressed_value (1, 0) ENER 

df E. ah 
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mf =:= uncompressed_value (1, 0) E "is 
frag offset =:= uncompressed_value (13, 0) [ 23: J} 
ttl_hopl [ 81; 
next_header [ 81; 
ip_checksum =:= inferred ip v4 header checksum ës 
src addr [ 32 1; 
dest_addr [ 32 1; 
extension headers =:= baseheader extension headers [ VARIABLE ]; 
spi [ 32 ], 
sequence number [ 32 ]; 

} 

UNCOMPRESSED v6 { 
ENFORCE (msn.UVALUE == (sequence number.UVALUE % 65536)); 
ENFORCE (ip id behavior innermost.UVALUE == IP ID BEHAVIOR RANDOM), 
outer headers =:= baseheader outer headers [ VARIABLE ]; 
ip version =:= uncompressed_value (4, 6) [ 4 1; 
tos_tc [ 8 ], 
flow label [ 20 ]; 
payload_length =:= inferred_ip_v6_length [ 16 ]; 
next header [ 8 1; 
tt1_hopl [ 8 1; 
src_addr [ 128 1; 
dest_addr [ 128 ]; 
extension headers =:= baseheader extension headers [ VARIABLE ]; 
spi [ 32 ]; 
sequence_number [ 32 J3 
df =:= uncompressed_value (0,0) [ 0]; 
ip_id =:= uncompressed_value (0,0) [ 0-15 

) 

CONTROL ( 
ENFORCE (profile value == PROFILE ESP 0103), 
ENFORCE (profile == profile value); 
ENFORCE (ip id behavior innermost.UVALUE == ip id behavior value), 
ENFORCE (reorder ratio.UVALUE == reorder ratio value), 

} 

DEFAULT { 
ENFORCE (outer ip flag == 0); 
tos_tc =:= static; 
dest_addr =:= static; 
ttl_hopl =:= static; 
src addr =:= static; 
df =:= static; 
flow label =:= static; 
next_header =:= static; 
spi =:= static; 
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sequence_number =:= static; 
reorder_ratio =:= static; 
ip_id_behavior_innermost =:= static; 


} 


// Replacement for UOR-2-ext3 
COMPRESSED co_common { 


ENFORCE (outer ip flag == outer ip indicator.CVALUE), 
discriminator Sos: 11111010’ [ 8 ]: 
ip id indicator =:= irregular(1) ET: TS 
header crce =:= crc7(THIS.UVALUE, THIS.ULENGTH) LAA lg 
flags_indicator =:= irregular(1) toh, Ok 
ttl hopl indicator =:= irregular(1) PE de 
tos tc indicator =:= irregular(1) LB S- 
reorder_ratio =:= irregular (2) Decke: 
control crc3 =:= control crc3 encoding [3 de 
outer ip indicator : df : ip id behavior innermost =:= 

profile 2 3 4 flags enc ( 

flags indicator.CVALUE, ip version. UVALUE) PO 8: 15 
tos tc =:= static or irreg(tos tc indicator.CVALUE, 8) [ 0, 8]; 
ttl hopl =:= static or irreg(ttl hopl indicator.CVALUE, 

ttl hopl.ULENGTH) [ O, 8 1; 
sequence number =:= 

sdv1 sn 1sb (sequence number.ULENGTH) [ VARIABLE ]; 
ip id -:- ip id sequential variable(ip id behavior innermost.UVALUE, 

ip id indicator. CVALUE) [ 0; Bi 16:15 


} 


// Sequence number sent instead of MSN due to field length 
// UO-0 
COMPRESSED pt_0_crc3 { 


discriminator =:= '0' [ 1 17 
sequence number =:= msn_lsb (4) [ 4 ]; 
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 
ip_id =:= inferred_sequential_ip_id EO: “ey 
} 
// New format, Type 0 with strong CRC and more SN bits 
COMPRESSED pt_O_crc7 { 
discriminator =:= '100’ klo 
sequence number =:= msn_lsb (6) [ 6 1: 
header crce =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 
ip id =:= inferred sequential ip id Oz ls 


} 


// UO-1-ID replacement (PT-1 only used for sequential) 
COMPRESSED pt 1 seq id { 


Pelletier & Sandlund Standards Track [Page 88] 


RFC 5225 ROHCv2 Profiles April 2008 


ENFORCE ( (ip_id_behavior_innermost .UVALUE == 
IP_ID_BEHAVIOR_SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)), 
discriminator =:= "101! 
header crce =:= crc3 (THIS.UVALUE, THIS.ULENGTH) 
sequence number =:= msn_lsb (6) 
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4) 
} 


.n 


KÉ 


saa 

BOW W 

ia is ess 
~ 


KÉ 


// UOR-2-ID replacement 
COMPRESSED pt 2 seq id { 
ENFORCE ((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED) ); 
discriminator =y= 71107 
ip id =:= ip id Isb(ip id behavior innermost.UVALUE, 6) 
header crce =:= crc7(THIS.UVALUE, THIS.ULENGTH) 
sequence number =:= msn_1lsb (8) 


e` 


m m ae 

oo W 

ia is Lei ki 
nen 


mo 


} 


ARA AAA AAA III III II III III II III III II III III 
// IP-only profile 
ARA AAA AAA II III III II III III II III III I III I/II 


iponly_baseheader (profile_value, outer_ip_flag, ip_id_behavior_value, 
reorder_ratio_value) 
{ 
UNCOMPRESSED v4 { 


outer headers =:= baseheader outer headers [ VARIABLE ]; 
ip_version =:= uncompressed_value (4, 4) [ 4 1; 
header length =:= uncompressed value(4, 5) [ 41; 
tos_tc [ 81; 
length =:= inferred ip v4 length [ 16 1; 
ip_id [ 16 1; 
rf =:= uncompressed_value(1, 0) E, le ale 
df [ 1]; 
mf =:= uncompressed value(1, 0) LCE Jr 
frag offset =:= uncompressed value(13, 0) NES OK 
ttl hopl [ 8 ]; 
next_header k Or dey 
ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ]; 
src_addr [32-10 
dest_addr [ 32715 
extension headers -:- baseheader extension headers [ VARIABIE ], 
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UNCOMPRESSED v6 { 


ENFORCE (ip id behavior innermost.UVALUE == IP ID BEHAVIOR RANDOM), 
outer headers =:= baseheader outer headers [ VARIABLE ]; 
ip_version =:= uncompressed_value (4, 6) [ 4 1; 
tos_tc [ 8 1; 
flow_label [ 20 1; 
payload_length =:= inferred ip v6 length [> 3165:14 
next header [ 8 1; 
ttl_hopl [ 8 1; 
src addr [ 128 ]; 
dest_addr [ 128 ]; 
extension headers =:= baseheader_extension_headers [ VARIABLE ]; 
df =:= aadd. value(0,0) [ 0 1]; 
ip id =:= uncompressed_value (0,0) [ 0]; 
} 
CONTROL { 
ENFORCE (profile_value == PROFILE_IP_0104); 
ENFORCE (profile == profile_value); 
ENFORCE (reorder_ratio.UVALUE == reorder_ratio_value); 
ENFORCE (ip id behavior innermost.UVALUE == ip id behavior value), 
} 
DEFAULT { 
ENFORCE (outer_ip_flag == 0); 
tos_tc =:= static; 
dest_addr =:= static; 
ttl_hopl =:= static; 
src_addr =:= static; 
df =:= static; 
flow_label =:= static; 
next_header =:= static; 
reorder ratio =:= static; 
ip_id_behavior_innermost =:= static; 


} 


// Replacement for UOR-2-ext3 
COMPRESSED co common { 


ENFORCE (outer ip flag == outer_ip_indicator.CVALUE) ; 
discriminator =:= ’11111010’ [ 8 ]; 
ip_id_indicator =:= irregular (1) Leek cl 
header crce =:= crc7(THIS.UVALUE, THIS.ULENGTH) PA %5 
flags_indicator =:= irregular(1) BL es 
ttl_hopl_indicator =:= irregular(1) L.- 15 
tos_tc_indicator =:= irregular(1) Pali Ie 
reorder ratio =:= irregular(2) E ST 
control crc3 =:= control crc3 encoding ES ts 
outer ip indicator : df : ip id behavior innermost =:= 
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profile_2_3_4_flags_enc ( 


flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ]; 
tos tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ O, 8 ]; 
ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE, 
ttl hopl.ULENGTH) [ O, 8 1; 
msn =:= msn_lsb(8) [ 8 ]; 
ip id -:- ip id sequential variable(ip id behavior innermost.UVALUE, 
ip id indicator. CVALUE) [ 0, 8, 16 Is 
} 
// UO-0 
COMPRESSED pt 0 crc3 { 
discriminator =:= '0' [ 1 17 
msn =:= msn_lsb(4) [ 4 ]; 
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 
ip_id =:= inferred_sequential_ip_id LL 


} 


// New format, Type 0 with strong CRC and more SN bits 
COMPRESSED pt D crc7 { 


discriminator =:= ’100’ Tees Sea 
msn =:= msn_lsb(6) [ 6 ]; 
header crce =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 
ip_id =:= inferred_sequential_ip_id E 9:15 
} 
// UO-1-ID replacement (PT-1 only used for sequential) 
COMPRESSED pt 1 seq id { 
ENFORCE ((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)), 
discriminator =:= ’101’ [3 15 
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 23% Is 
msn =:= msn_lsb(6) KLS ks 
ip id =:= ip id lsb(ip_id behavior innermost.UVALUE, 4) [ 4 1; 
} 
// UOR-2-ID replacement 
COMPRESSED pt. 2 seq id { 
ENFORCE((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)), 
discriminator =:= ’110’ L- 3:15 
ip id -:- ip_id_lsb(ip_id_behavior_innermost.UVALUE, 6) [ 6 1; 
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) Le She fies 
msn =:= msn_lsb(8) [ 8 ]; 
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} 


ARA AAA AA AAA AAA AAA AAA AAA AAA AAA AAA 
// UDP-lite/RTP profile 
ARA AAA III III II III III II AAA 


udplite_rtp_baseheader (profile_value, ts_stride_value, 
time_stride_value, outer_ip_flag, 
ip_id_behavior_value, reorder_ratio_value, 
coverage_behavior_value) 


UNCOMPRESSED v4 { 


ENFORCE (msn .UVALUE == sequence number.UVALUE), 
outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 
ip_version =:= uncompressed_value (4, 4) [ 415 
header_length =:= uncompressed_value(4, 5) [ 41; 
tos_tc [ 81; 
length =:= inferred_ip_v4_length [ 16 ]; 
ip_id [ 16 ]; 
EE =:= uncompressed_value (1, 0) E. U 
df LE Ve 
mf =:= uncompressed_value (1, 0) Po ts 
frag offset =:= uncompressed_value (13, 0) [13 Is 
ttl_hopl [ 81; 
next_header #85 Jy 
ip checksum =:= inferred ip v4 header checksum E Lo ls 
src addr [ 32 1; 
dest_addr [ 32 1; 
extension headers =:= baseheader extension headers [ VARIABLE ]; 
src port [ 16 17 
dst port [ 16 17 
checksum coverage [ 16 17 
udp checksum [ 16 ], 
rtp version =:= uncompressed_value (2, 2) [ 21; 
pad_bit [ 11; 
extension EP a E 
cc [ 4 ]; 
marker E, Ad 
payload_type [ 717 
sequence_number [ 16 ]; 
timestamp [ 32 1; 
ssrc [32] 
csrc list [ VARIABLE ]; 
} 
UNCOMPRESSED v6 { 
ENFORCE (ip id behavior innermost.UVALUE == IP ID BEHAVIOR RANDOM), 
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outer headers =:= baseheader outer headers [ VARIABLE ]; 
ip version =:= uncompressed_value (4, 6) [ 4 1; 
tos tc [ 8 1; 
flow_label [ 20 ]; 
payload length =:= inferred ip v6 length [ 16 ]; 
next_header [ 8 1; 
tt1_hopl [ 8 1; 
src addr [ 128 ], 
dest addr [ 128 ], 
extension headers =:= baseheader extension headers [ VARIABLE ]; 
src port [ 16]; 
dat port [ 16]; 
checksum coverage [ 16 ]; 
udp_checksum [ 16 ]; 
rtp_version =:= uncompressed_value(2, 2) [ Dis] rg 
pad bit [ I. 1% 
extension [ Jo eg 
cc [ 4 Ty 
marker [ 1 1; 
payload_type [ 71; 
sequence_number [ 16 ]; 
timestamp L 32:75 
ssrc [ 327% 
csrc list [ VARIABLE ]; 
df =:= uncompressed_value (0,0) [ 0]; 
ip id =:= uncompressed_value (0,0) [ 0]; 

} 

CONTROL { 
ENFORCE (profile_value == PROFILE_RTP_0107); 
ENFORCE (profile == profile_value); 
ENFORCE (time_stride.UVALUE == time_stride_value); 
ENFORCE (ts_stride.UVALUE == ts_stride_value); 
ENFORCE (coverage_behavior.UVALUE == coverage_behavior_value); 
ENFORCE (reorder_ratio.UVALUE == reorder_ratio_value); 
ENFORCE (ip id behavior innermost.UVALUE == ip id behavior value), 
dummy field -:- field scaling(ts stride.UVALUE, 

ts scaled.UVALUE, timestamp.UVALUE, ts offset.UVALUE) [ 0 1; 
} 
INITIAL { 


ts_stride 
time_stride 


} 


uncompressed_value (32, TS_STRIDE_DEFAULT); 
uncompressed_value (32, TIME_STRIDE_DEFAULT); 


DEFAULT { 
ENFORCE (outer ip flag == 0); 
tos tc =:= static; 
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dest_addr =:= static; 
ttl_hopl =:= static; 

src addr =:= static; 

df =:= static; 

flow label =:= static; 
next_header =:= static; 
src_port =:= static; 
dst_port =:= static; 
pad_bit =:= static; 
extension =:= static; 

ce =:= static; 

// When marker not present in packets, it is assumed 0 
marker =:= uncompressed_value (1, 0); 
payload_type =:= static; 
sequence_number =:= static; 
timestamp =:= static; 

ssrc =:= static; 

csrc list =:= static; 
ts_stride =:= static; 
time_stride =:= static; 
ts_scaled =:= static; 
ts_offset =:= static; 
reorder_ratio =:= static; 
ip_id_behavior_innermost =:= static; 


} 


// Replacement for UOR-2-ext3 
COMPRESSED co_common { 


ENFORCE (outer ip flag == outer ip indicator.CVALUE), 
discriminator =:= "11111010" [228 > dG 
marker =:= irregular (1) fe Wee Kara 
header crce =:= crc7(THIS.UVALUE, THIS.ULENGTH) ETS 
flagsl indicator =:= irregular(1) Pt, 5 
flags2 indicator =:= irregular(1) Lx ale 
tsc_indicator =:= irregular (1) Et Te 
tss_indicator =:= irregular (1) LT 
ip_id_indicator =:= irregular (1) Ek Es 
control crc3 =:= control crc3 encoding [Sd 
outer ip indicator : ttl_hopl_indicator 

tos tc indicator : df : ip id behavior_innermost : reorder_ratio 

=:= profile 1 7 flagsl enc(flagsl indicator.CVALUE, 

ip version. UVALUE) Qi. Se 

list indicator : pt indicator : tis indicator : pad bit 

extension : coverage behavior =:= 

profile 7 flags2 enc(flags2 indicator. CVALUE) [0,8]; 
tos tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8]; 
ttl_hopl =:= 
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static_or_irreg(ttl_hopl_indicator.CVALUE, 8) [0,8]; 
payload type =:= pt_irr_or_static(pt_indicator.CVALUE) [ 0, 8 ]; 
sequence_number =:= 

sdvl_sn_lsb (sequence_number.ULENGTH) [ VARIABLE ]; 
ip id -:- ip id sequential variable(ip id behavior innermost.UVALUE, 

ip id indicator. CVALUE) 1.05.85, W6: 15 
ts_scaled =:= variable_scaled_timestamp (tss_indicator.CVALUE, 

tsc_indicator.CVALUE, ts_stride.UVALUE, 

time_stride.UVALUE) [ VARIABLE ]; 
timestamp =:= variable_unscaled_timestamp (tss_indicator.CVALUE, 

tsc_indicator.CVALUE) [ VARIABLE ]; 


] 
ts_stride =:= sdvl_or_static(tss_indicator.CVALUE) [ VARIABLE ]; 
time_stride =:= sdvl_or_static(tis_indicator.CVALUE) [ VARIABLE ] 
csrc list =: 

csrc_list_presence (list_indicator.CVALUE, 


cc.UVALUE) [ VARIABLE ]; 

} 
// UO-0 
COMPRESSED pt_0_crc3 { 

discriminator =:= '0' [ 1 17 

msn =:= msn_lsb (4) [4]; 

header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 

timestamp =:= inferred_scaled_field [015 

ip_id =:= inferred sequential ip id E0]? 


} 


// New format, Type 0 with strong CRC and more SN bits 
COMPRESSED pt_0_crc7 { 


discriminator =:= '1000' [4 ]; 
msn =:= msn_lsb (5) Loe 
header crce =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 
timestamp =:= inferred_scaled_field [ 0 ]; 
ip_id =:= inferred_sequential_ip_id [ 0 ]; 
} 
// UO-1 replacement 
COMPRESSED pt 1 rnd { 
ENFORCE (ts stride.UVALUE != 0); 
ENFORCE ((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR RANDOM) || 
(ip id behavior innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 
discriminator =:= '101' LS ds 
marker =:= irregular (1) ; 
msn =:= msn_1lsb (4) H 


ts. scaled scaled ts 1sb(time stride.UVALUE, 5) 
header crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) 


E 


GA Ui H 
ia is ss es 


[ 
[ 
[ 
[ 


LA 
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// UO-1-ID replacement 
COMPRESSED pt.1 seq id { 
ENFORCE ((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)), 


discriminator =:= ’1001’ E RE 

ip id =:= ip id lsb(ip_id behavior innermost.UVALUE, 4) [4 1; 

msn =:= msn Isb (5) [ 5 1; 

header crc = crc3 (THIS.UVALUE, THIS.ULENGTH) [23s us 

timestamp =:= inferred scaled field [ 0 ]; 
} 
// U0-1-TS replacement 
COMPRESSED pt 1 seq ts { 

ENFORCE (ts stride.UVALUE != 0), 

ENFORCE((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)), 

discriminator =:= ’101’ [ 3 ]; 

marker =:= irregular (1) Li "Ae 

msn =:= msn_lsb (4) [41]; 

ts_scaled =:= scaled_ts_lsb (time_stride.UVALUE, 5) [5]; 

header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) LS 14 

ip_id =:= inferred_sequential_ip_id [ 0 ]; 

} 
// UOR-2 replacement 
COMPRESSED pt_2_rnd { 

ENFORCE (ts stride.UVALUE != 0); 

ENFORCE ( (ip_id_behavior_innermost .UVALUE == 
IP_ID_BEHAVIOR_RANDOM) | | 
(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 

discriminator =:= ’110’ D 3h le 

msn =:= msn_lsb(7) k #15 

ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 6) [ 6 ]; 

marker =:= irregular (1) E Y 

header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) ESTE 

} 
// UOR-2-ID replacement 
COMPRESSED pt 2 seq id { 

ENFORCE ((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)), 

discriminator =:= ' 11000” 945 
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msn =:= msn_lsb (7) [ 71; 
ip id =:= ip id Isb(ip id behavior innermost.UVALUE, 5) [ 5 1; 
header crce =:= crc7(THIS.UVALUE, THIS.ULENGTH) kk 
timestamp =:= inferred scaled field ko T? 
} 
// UOR-2-ID-ext1 replacement (both TS and IP-ID) 
COMPRESSED pt_2_seq_both { 
ENFORCE (ts_stride.UVALUE != 0); 
ENFORCE ( (ip_id_behavior_innermost .UVALUE == 
IP_ID_BEHAVIOR_SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)), 
discriminator =:= ’11001’ K5: 1% 
msn =:= msn_lsb (7) L 7:15 
ip id -:- ip_id_lsb(ip_id_behavior_innermost.UVALUE, 5) [ 5 1; 
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) zk 
ts. scaled =:= scaled ts Isb(time stride.UVALUE, 7) [ls 
marker =:= irregular (1) E 2715 
} 
// UOR-2-TS replacement 
COMPRESSED pt 2 seq ts { 
ENFORCE (ts stride.UVALUE != 0), 
ENFORCE((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)), 
discriminator =:= ’1101’ LA 1; 
msn =:= msn 1sb(7) [7 ]; 
ts_scaled =:= scaled ts Isb(time stride.UVALUE, 5) [ 5 ]; 
marker =:= irregular(1) LA ds 
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [7]; 
ip_id =:= inferred_sequential_ip_id E Se 


} 


ARA AAA AAA AAA AAA AA AAA AAA AAA AAA AAA AAA 
// UDP-lite profile 
ARA AAA AAA AAA AA AAA AAA ATTA III II III TT 


udplite baseheader (profile value, outer ip flag, ip id behavior value, 
reorder ratio value, coverage behavior value) 
{ 
UNCOMPRESSED v4 { 


outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 
ip_version =:= uncompressed_value (4, 4) E 4. lg 
header length =:= uncompressed_value (4, 5) [ 41; 
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tos_tc [ 81; 
length =:= inferred ip v4 length [ 16 1; 
ip_id [ 16 1; 
KE: =:= uncompressed_value (1, 0) ke, ee] 
df [de Vs 
mf =:= uncompressed_value (1, 0) EL DE 
frag_offset =:= uncompressed_value (13, 0) [L 73215 
ttl_hopl [ 81; 
next_header L-8 ks 
ip checksum =:= inferred ip v4 header checksum [ 16 1; 
src_addr [ 32 1; 
dest_addr [ 32 1; 
extension headers =:= baseheader extension headers [ VARIABLE ]; 
src_port [ 16 1; 
dst_port [ 16 1; 
checksum_coverage [ 16 1; 
udp_checksum [ 36.5 

} 

UNCOMPRESSED v6 { 
ENFORCE (ip id behavior innermost.UVALUE == IP ID BEHAVIOR RANDOM), 
outer headers =:= baseheader outer headers [ VARIABLE ]; 
ip_version =:= uncompressed_value (4, 6) [ 4 1; 
tos tc [ 8 ], 
flow label [ 201; 
payload length =:= inferred ip v6 length E Ze, Te 
next header [ 8 1; 
ttl_hopl [ 8 1; 
src addr [ 128 ], 
dest addr [ 128 ], 
extension headers =:= baseheader extension headers [ VARIABLE ]; 
src port [ 16]; 
dst port [ 16 ]; 
checksum_coverage [ 16 ]; 
udp_checksum [ 16 ]; 
df =:= uncompressed_value (0,0) [ O 1; 
ip id =:= uncompressed_value (0,0) [ O li 

} 

CONTROL { 
ENFORCE (profile_value == PROFILE_UDPLITE_0108); 
ENFORCE (profile == profile_value); 
ENFORCE (coverage_behavior.UVALUE == coverage_behavior_value); 
ENFORCE (reorder_ratio.UVALUE == reorder_ratio_value); 
ENFORCE (ip id behavior innermost.UVALUE == ip id behavior value), 

} 

DEFAULT { 
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ENFORCE (outer ip flag == 0); 
tos_tc =:= static; 
dest_addr =:= static; 
ttl_hopl =:= static; 
src_addr =:= static; 
df =:= static; 
flow_label =:= static; 
next_header =:= static; 
src port =:= static; 
dst_port =:= static; 
reorder_ratio =:= static; 
ip_id_behavior_innermost =:= static; 


} 


// Replacement for UOR-2-ext3 
COMPRESSED co_common { 


ENFORCE (outer ip flag == outer ip indicator.CVALUE), 
discriminator =:= 711111010’ [ 8 ]; 
ip_id_indicator =:= irregular (1) E 22465 
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) DA Tes 
flags_indicator =:= irregular(1) EL he 
ttl hopl indicator =:= irregular(1) L-E I 
tos tc indicator =:= irregular(1) [tii 
reorder_ratio =:= irregular (2) WEE: 
control crc3 =:= control crc3 encoding L:3 Ty 
outer ip indicator : df : ip id behavior innermost 
coverage behavior =:= 
profile 8 flags enc(flags indicator.CVALUE, 
ip version.UVALUE) [ O, 8 1; 
tos tc -:- static or irreg(tos tc indicator.CVALUE, 8) [ 0, 8]; 
ttl hopl =:= static or irreg(ttl hopl indicator.CVALUE, 
ttl hopl.ULENGTH) [Oy 8° J3 
msn =:= msn_lsb(8) Aes ae he 
ip id =:= ip id sequential variable(ip id behavior innermost.UVALUE, 
ip id indicator. CVALUE) [ O, 8, 16 ], 
} 
// UO-0 
COMPRESSED pt_0_crc3 { 
discriminator =:= '0' [ 1 1; 
msn =:= msn_1sb(4) [4]; 
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 
ip_id =:= inferred_sequential_ip_id [ 0 ]; 


} 


// New format, Type 0 with strong CRC and more SN bits 
COMPRESSED pt_O_crc7 { 
discriminator =:= '100' E315 
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msn =:= msn_lsb(6) [ 6 ]; 
header crce =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 
ip_id =:= inferred_sequential_ip_id [ 0 ]; 
} 
// UO-1-ID replacement (PT-1 only used for sequential) 
COMPRESSED pt 1 seq id { 
ENFORCE ((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)), 
discriminator =:= ’101’ Week 
header crce =:= crc3(THIS.UVALUE, THIS.ULENGTH) 73:15 
msn =:= msn_lsb (6) [ 6 1; 
ip id =:= ip id Isb(ip id behavior innermost.UVALUE, 4) [ 4 1; 
} 
// UOR-2-ID replacement 
COMPRESSED pt. 2 seq id { 
ENFORCE ((ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL) || 
(ip id behavior innermost.UVALUE == 
IP ID BEHAVIOR SEQUENTIAL SWAPPED)), 
discriminator =:= '110' KS "jg 
ip id -:- ip id Isb(ip id behavior innermost.UVALUE, 6) [ 6 1; 
header crce =:= crc7(THIS.UVALUE, THIS.ULENGTH) KO TG 
msn =:= msn 1sb(8) [ 8 17 


6.9. Feedback Formats and Options 
6.9.1. Feedback Formats 


This section describes the feedback format for ROHCv2 profiles, using 
the formats described in Section 5.2.3 of [RFC4995]. 


The Acknowledgment Number field of the feedback formats contains the 
least significant bits of the MSN (see Section 6.3.1) that 
corresponds to the reference header that is being acknowledged. A 
reference header is a header that has been successfully CRC-8 
validated or CRC verified. If there is no reference header 
available, the feedback MUST carry an ACKNUMBER-NOT-VALID option. 
FEEDBACK-1 
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0 1 2 3 4 5 6 7 
444444444 
| Acknowledgment Number | 
444444444 


Acknowledgment Number: The eight least significant bits of the 
MSN. 


A FEEDBACK-1 is an ACK. In order to send a NACK or a STATIC-NACK, 
FEEDBACK-2 must be used. 


FEEDBACK-2 


0 J 2 3 4 5 6 7 
444444444 
|Acktype| Acknowledgment Number | 
444444444 
| Acknowledgment Number | 
444444444 
| CRC | 
444444444 
/ Feedback options / 
444444444 


Acktype: 
0 = ACK 
1 = NACK 
2 = STATIC-NACK 


3 is reserved (MUST NOT be used for parsability) 
Acknowledgment Number: The least significant bits of the MSN. 


CRC: 8-bit CRC computed over the entire feedback payload including 
any CID fields but excluding the feedback type, the ’Size’ field, 
and the ’Code’ octet, using the polynomial defined in Section 
5.3.1.1 of [RFC4995]. If the CID is given with an Add-CID octet, 
the Add-CID octet immediately precedes the FEEDBACK-1 or 
FEEDBACK-2 format. For purposes of computing the CRC, the CRC 
field is zero. 


Feedback options: A variable number of feedback options, see 
Section 6.9.2. Options may appear in any order. 


Pelletier & Sandlund Standards Track [Page 101] 


RFC 5225 ROHCv2 Profiles April 2008 


A FEEDBACK-2 of type NACK or STATIC-NACK is always implicitly an 
acknowledgment for a successfully decompressed packet, which 
corresponds to a packet whose LSBs match the Acknowledgment Number of 
the feedback element, unless the ACKNUMBER-NOT-VALID option (see 
Section 6.9.2.2) appears in the feedback element. 


The FEEDBACK-2 format always carries a CRC and is thus more robust 
than the FEEDBACK-1 format. When receiving FEEDBACK-2, the 
compressor MUST verify the information by computing the CRC and 
comparing the result with the CRC carried in the feedback format. If 
the two are not identical, the feedback element MUST be discarded. 


6.9.2. Feedback Options 


A feedback option has variable length and the following general 
format: 


0 1 2 3 4 5 6 7 
+---4--- 4-44 4444 
| Opt Type | Opt Len | 
+---4--- 4-4 44-44 + 
/ Option Data / Opt Len (octets) 
+---4--- 4-4 44-444 


Opt Type: Unsigned integer that represents the type of the 
feedback option. Section 6.9.2.1 through Section 6.9.2.4 
describes the ROHCv2 feedback options. 


Opt Len: Unsigned integer that represents the length of the Option 
Data field, in octets. 


Option Data: Feedback type specific data. Present if the value of 
the Opt Len field is set to a non-zero value. 


6.9.2.1. The REJECT Option 


The REJECT option informs the compressor that the decompressor does 
not have sufficient resources to handle the flow. 


0 1 2 3 4 5 6 7 
+---+---+---+---+---+---+---+---+ 
| Opt Type = 2 | Opt Len = 0 | 
+---+---+---+---+---+---+---+---+ 


When receiving a REJECT option, the compressor MUST stop compressing 


the packet flow, and SHOULD refrain from attempting to increase the 
number of compressed packet flows for some time. The REJECT option 
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MUST NOT appear more than once in the FEEDBACK-2 format; otherwise, 
the compressor MUST discard the entire feedback element. 


6.9.2.2. The ACKNUMBER-NOT-VALID Option 


The ACKNUMBER-NOT-VALID option indicates that the Acknowledgment 
Number field of the feedback is not valid. 


0 1 2 3 4 5 6 7 
+---4---4-- 4-4 4-44 + 
| Opt Type - 3 | Opt Len = 0 | 
Ho ooo ooo 4-44 + 


A compressor MUST NOT use the Acknowledgment Number of the feedback 
to find the corresponding sent header when this option is present. 
When this option is used, the Acknowledgment Number field of the 
FEEDBACK-2 format is set to zero. Consequently, a NACK or a STATIC- 
NACK feedback type sent with the ACKNUMBER-NOT-VALID option is 
equivalent to a STATIC-NACK with respect to the type of context 
repair requested by the decompressor. 


The ACKNUMBER-NOT-VALID option MUST NOT appear more than once in the 
FEEDBACK-2 format; otherwise, the compressor MUST discard the entire 
feedback element. 


6.9.2.3. The CONTEST MEMORY Option 


The CONTEXT_MEMORY option informs the compressor that the 
decompressor does not have sufficient memory resources to handle the 
context of the packet flow, as the flow is currently compressed. 


0 1 2 3 4 5 6 7 
Ho oo 4-4 4-44 + 
| Opt Type - 9 | Opt Len = 0 | 
+---4---4-- 4-4 4-44 + 


When receiving a CONTEXT_MEMORY option, the compressor SHOULD take 
actions to compress the packet flow in a way that requires less 
decompressor memory resources or stop compressing the packet flow. 
The CONTEXT_MEMORY option MUST NOT appear more than once in the 
FEEDBACK-2 format; otherwise, the compressor MUST discard the entire 
feedback element. 


6.9.2.4. The CLOCK_RESOLUTION Option 
The CLOCK_RESOLUTION option informs the compressor of the clock 


resolution of the decompressor. It also informs whether or not the 
decompressor supports timer-based compression of the RTP TS timestamp 
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(see Section 6.6.9). The CLOCK_RESOLUTION option is applicable per 
channel, i.e., it applies to any context associated with a profile 
for which the option is relevant between a compressor and 
decompressor pair. 


0 1 2 3 4 5 6 7 
44444444 + 
| Opt Type = 10 | Opt Len = 1 | 
+44 444444 
| Clock resolution (ms) | 
+44 444444 


Clock resolution: Unsigned integer that represents the clock 
resolution of the decompressor expressed in milliseconds. 


The smallest clock resolution that can be indicated is 1 millisecond. 
The value zero has a special meaning: it indicates that the 
decompressor cannot do timer-based compression of the RTP Timestamp. 
The CLOCK_RESOLUTION option MUST NOT appear more than once in the 
FEEDBACK-2 format; otherwise, the compressor MUST discard the entire 
feedback element. 


6.9.2.5. Unknown Option Types 


If an option type other than those defined in this document is 
encountered, the compressor MUST discard the entire feedback element. 


7. Security Considerations 


Impairments such as bit errors on the received compressed headers, 
missing packets, and reordering between packets could cause the 
header decompressor to reconstitute erroneous packets, i.e., packets 
that do not match the original packet, but still have a valid IP, UDP 
(or UDP-Lite), and RTP headers, and possibly also valid UDP (or UDP- 
Lite) checksuns. 


The header compression profiles defined herein use an internal 
checksum for verification of reconstructed headers. This reduces the 
probability that a header decompressor delivers erroneous packets to 
upper layers without the error being noticed. In particular, the 
probability that consecutive erroneous packets are not detected by 
the internal checksum is close to zero. 


This small but non-zero probability remains unchanged when integrity 
protection is applied after compression and verified before 
decompression, in the case where an attacker could discard or reorder 
packets between the compression endpoints. 
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The impairments mentioned above could be caused by a malfunctioning 
or malicious header compressor. Such corruption may be detected with 
end-to-end integrity mechanisms that will not be affected by the 
compression. Moreover, the internal checksum can also be useful in 
the case of malfunctioning compressors. 


Denial-of-service attacks are possible if an intruder can introduce 
(for example) bogus IR or FEEDBACK packets onto the link and thereby 
cause compression efficiency to be reduced. However, an intruder 
having the ability to inject arbitrary packets at the link layer in 
this manner raises additional security issues that dwarf those 
related to the use of header compression. 


8. IANA Considerations 


The following ROHC profile identifiers have been assigned by the IANA 
for the profiles defined in this document: 


Identifier Profile 

0x0101 ROHCv2 RTP 

0x0102 ROHCv2 UDP 

0x0103 ROHCv2 ESP 

0x0104 ROHCv2 IP 

0x0107 ROHCv2 RTP/UDP-Lite 
0x0108 ROHCv2 UDP-Lite 
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Appendix A. Detailed Classification of Header Fields 


Header compression is possible due to the fact that most header 
fields do not vary randomly from packet to packet. Many of the 
fields exhibit static behavior or change in a more or less 
predictable way. When designing a header compression scheme, it is 
of fundamental importance to understand the behavior of the fields in 
detail. 


In this appendix, all fields in the headers compressible by these 
profiles are classified and analyzed. The analysis is based on 
behavior for the types of traffic that are expected to be the most 
frequently compressed (e.g., RTP field behavior is based on voice 
and/or video traffic behavior). 


Fields are classified as belonging to one of the following classes: 


INFERRED - These fields contain values that can be inferred from 
other values, for example the size of the frame carrying the packet, 
and thus do not have to be included in compressed packets. 


STATIC - These fields are expected to be constant throughout the 
lifetime of the flow; in general, it is sufficient to design a 
compressed format so that these fields are only updated by IR 
packets. 


STATIC-DEF - These fields are expected to be constant throughout the 
lifetime of the flow and their values can be used to define a flow. 
They are only sent in IR packets. 


STATIC-KNOWN - These fields are expected to have well-known values 
and therefore do not need to be communicated at all. 


SEMISTATIC - These fields are unchanged most of the time. However, 
occasionally the value changes but will revert to its original value. 
For ROHCv2, the values of such fields do not need to be possible to 
change with the smallest compressed packet formats, but should be 
possible to change via slightly larger compressed packets. 


RARELY CHANGING (RACH) - These are fields that change their values 
occasionally and then keep their new values. For ROHCv2, the values 
of such fields do not need to be possible to change with the smallest 
compressed packet formats, but should be possible to change via 
slightly larger compressed packets. 


IRREGULAR - These are the fields for which no useful change pattern 


can be identified and should be transmitted uncompressed in all 
compressed packets. 
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PATTERN - These are fields that change between each packet, but 
change in a predictable pattern. 


A.1. IPv4 Header Fields 


Version 
Header Length 
| Type Of Service 

| Packet Length 

| Identification 

| Sequential 
| Seq. swap 
Random 

| zero 

| Reserved flag 
| 

| 

| 

| 


Don’t Fragment flag 
More Fragments flag 
Fragment Offset 
Time To Live 
Protocol 

Header Checksum 
Source Address 
Destination Address 


Version 


+—+ 


+ --—— 4441 


STATIC-KNOWN 
STATIC-KNOWN 
RACH 
INFERRED 


PATTERN 
PATTERN 
IRREGULAR 
STATIC 
STATIC-KNOWN 
RACH 
STATIC-KNOWN 
STATIC-KNOWN 
RACH 
STATIC-DEF 
INFERRED 
STATIC-DEF 
STATIC-DEF 


The version field states which IP version is used and is set to 


the value four. 


Header Length 


As long as no options are present in the IP header, the header 


length is constant with the value five. 


If there are options, the 


field could be RACH or STATIC-DEF, but only option-less headers 
are compressed by ROHCv2 profiles. 
classified as STATIC-KNOWN. 


Type Of Service 


The field is therefore 


For the type of flows compressed by the ROHCv2 profiles, the DSCP 
(Differentiated Services Code Point) 
Notification) fields are expected to change relatively seldom. 
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Packet Length 


Information about packet length is expected to be provided by the 
link layer. The field is therefore classified as INFERRED. 


IPv4 Identification 


The Identification field (IP-ID) is used to identify what 
fragments constitute a datagram when reassembling fragmented 
datagrams. The IPv4 specification does not specify exactly how 
this field is to be assigned values, only that each packet should 
get an IP-ID that is unique for the source-destination pair and 
protocol for the time the datagram (or any of its fragments) could 
be alive in the network. This means that assignment of IP-ID 
values can be done in various ways, but the expected behaviors 
have been separated into four classes. 


Sequential 


In this behavior, the IP-ID is expected to increment by one for 
most packets, but may increment by a value larger than one, 
depending on the behavior of the transmitting IPv4 stack. 


Sequential Swapped 


When using this behavior, the IP-ID behaves as in the 
Sequential behavior, but the two bytes of IP-ID are byte- 
swapped. Therefore, the IP-ID can be swapped before 
compression to make it behave exactly as the Sequential 
behavior. 


Random 


Some IP stacks assign IP-ID values using a pseudo-random number 
generator. There is thus no correlation between the ID values 
of subsequent datagrams, and therefore there is no way to 
predict the IP-ID value for the next datagram. For header 
compression purposes, this means that the IP-ID field needs to 
be sent uncompressed with each datagram, resulting in two extra 
octets of header. 


zero 
This behavior, although not a legal implementation of IPv4, is 


sometimes seen in existing IPv4 stacks. When this behavior is 
used, all IP packets have the IP-ID value set to zero. 
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Flags 


The Reserved flag must be set to zero and is therefore classified 
as STATIC-KNOWN. The Don’t Fragment (DF) flag changes rarely and 
is therefore classified as RACH. Finally, the More Fragments (MF) 
flag is expected to be zero because IP fragments will not be 
compressed by ROHC and is therefore classified as STATIC-KNOWN. 


Fragment Offset 


Under the assumption that no fragmentation occurs, the fragment 
offset is always zero and is therefore classified as STATIC-KNOWN. 


Time To Live 
The Time To Live field is expected to be constant during the 
lifetime of a flow or to alternate between a limited number of 
values due to route changes. 


Protocol 


This field will have the same value in all packets of a flow and 
is therefore classified as STATIC-DEF. 


Header Checksum 
The header checksum protects individual hops from processing a 
corrupted header. When almost all IP header information is 
compressed away, there is no point in having this additional 
checksum; instead, it can be regenerated at the decompressor side. 
The field is therefore classified as INFERRED. 


Source and Destination addresses 


These fields are part of the definition of a flow and must thus be 
constant for all packets in the flow. 
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A. 


Li 


IPv6 Header Fields 
+---------------------- +---------------- + 
| Field | Class 
+---------------------- +---------------- + 
| version | STATIC-KNOWN | 
| Traffic Class | RACH 
| Flow Label | STATIC-DEF | 

Payload Length INFERRED 

Next Header STATIC-DEF 
| Hop Limit | RACH 
| Source Address | STATIC-DEF 
| Destination Address | STATIC-DEF | 
+---------------------- +---------------- + 
Version 


The version field states which IP version is used and is set to 
the value six. 


Traffic Class 


For the type of flows compressed by the ROHCv2 profiles, the DSCP 
and ECN fields are expected to change relatively seldom. 


Flow Label 


This field may be used to identify packets belonging to a specific 
flow. If it is not used, the value should be set to zero. 
Otherwise, all packets belonging to the same flow must have the 
same value in this field. The field is therefore classified as 
STATIC-DEF. 


Payload Length 
Information about packet length (and, consequently, payload 
length) is expected to be provided by the link layer. The field 
is therefore classified as INFERRED. 


Next Header 


This field will have the same value in all packets of a flow and 
is therefore classified as STATIC-DEF. 
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Hop Limit 


The Hop Limit field is expected to be constant during the lifetime 
of a flow or to alternate between a limited number of values due 
to route changes. 


Source and Destination addresses 


These fields are part of the definition of a flow and must thus be 
constant for all packets in the flow. The fields are therefore 
classified as STATIC-DEF. 


A.3 UDP Header Fields 
+------------------ +------------- + 
| Field | Class | 
+------------------ +------------- + 
| Source Port | STATIC-DEF | 
| Destination Port | STATIC-DEF | 
| Length | INFERRED | 
| Checksum | | 

Disabled STATIC 
Enabled IRREGULAR 
+------------------ +------------- + 


Source and Destination ports 


These fields are part of the definition of a flow and must thus be 
constant for all packets in the flow. 


Length 


Information about packet length is expected to be provided by the 
link layer. The field is therefore classified as INFERRED. 


Checksum 
The checksum can be optional. If disabled, its value is 
constantly zero and can be compressed away. If enabled, its value 


depends on the payload, which for compression purposes is 
equivalent to it changing randomly with every packet. 
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A.4. UDP-Lite Header Fields 
+--------- +------- + 
| Field | Class | 
EE EE + 
| Source Port | STATIC-DEF | 
| Destination Port | STATIC-DEF | 
| Checksum Coverage | | 

Zero STATIC-DEF 
Constant INFERRED 
| Variable | IRREGULAR | 
| Checksum | IRREGULAR | 
4-------------------- 4+------------- + 


Source and Destination Port 


These fields are part of the definition of a flow and must thus be 
constant for all packets in the flow. 


Checksum Coverage 


The Checksum Coverage field may behave in different ways: it may 
have a value of zero, it may be equal to the datagram length, or 
it may have any value between eight octets and the length of the 
datagram. From a compression perspective, this field is expected 
to either be entirely predictable (for the cases where it follows 
the same behavior as the UDP Length field or where it takes ona 
constant value) or to change randomly for each packet (making the 
value unpredictable from a header-compression perspective). For 
all cases, the behavior itself is not expected to change for this 
field during the lifetime of a packet flow, or to change 
relatively seldom. 


Checksum 


The information used for the calculation of the UDP-Lite checksum 
is governed by the value of the checksum coverage and minimally 
includes the UDP-Lite header. The checksum is a changing field 
that must always be sent as-is. 


Pelletier & Sandlund Standards Track [Page 114] 


RFC 5225 ROHCv2 Profiles April 2008 


A: 


Dis 


RTP Header Fields 
+---------------- +---------------- + 
| Field | Class | 
+---------------- +---------------- + 
| Version | STATIC-KNOWN | 
| Padding | RACH 
| Extension | RACH 
CSRC Counter RACH 
Marker SEMISTATIC 
| Payload Type | RACH 
| Sequence Number| PATTERN | 
| Timestamp | PATTERN | 
| SSRC | STATIC-DEF | 
| CSRC | RACH | 
+---------------- +---------------- + 
Version 
This field is expected to have the value two and the field is 
therefore classified as STATIC-KNOWN. 
Padding 
The use of this field is application-dependent, but when payload 
padding is used, it is likely to be present in most or all 
packets. The field is classified as RACH to allow for the case 
where the value of this field changes. 
Extension 
If RTP extensions are used by the application, these extensions 
are often present in all packets, although the use of extensions 
is infrequent. To allow efficient compression of a flow using 
extensions in only a few packets, this field is classified as 
RACH. 
CSRC Count 


This field indicates the number of CSRC items present in the CSRC 
list. This number is expected to be mostly constant on a packet- 
to-packet basis and when it changes, change by small amounts. As 
long as no RTP mixer is used, the value of this field will be 
zero. 
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Marker 


For audio, the marker bit should be set only in the first packet 
of a talkspurt, while for video, it should be set in the last 
packet of every picture. This means that in both cases the RTP 
marker is classified as SEMISTATIC. 


Payload Type 
Applications could adapt to congestion by changing payload type 
and/or frame sizes, but that is not expected to happen frequently, 


so this field is classified as RACH. 


RTP Sequence Number 


The RTP Sequence Number will be incremented by one for each packet 
sent. 


Timestamp 
In the audio case: 


As long as there are no pauses in the audio stream, the RIP 
Timestamp will be incremented by a constant value, which 
corresponds to the number of samples in the speech frame. It 
will thus mostly follow the RTP Sequence Number. When there 
has been a silent period and a new talkspurt begins, the 
timestamp will jump in proportion to the length of the silent 
period. However, the increment will probably be within a 
relatively limited range. 


In the video case: 


Between two consecutive packets, the timestamp will either be 
unchanged or increase by a multiple of a fixed value 
corresponding to the picture clock frequency. The timestamp 
can also decrease by a multiple of the fixed value for certain 
coding schemes. The change in timestamp value, expressed as a 
multiple of the picture clock frequency, is in most cases 
within a limited range. 


SSRC 
This field is part of the definition of a flow and must thus be 


constant for all packets in the flow. The field is therefore 
classified as STATIC-DEF. 
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The participants in a session, 
fields, 
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who are identified by the CSRC 
are usually expected to be unchanged on a packet-to-packet 


s, but will infrequently change by a few additions and/or 
removals. 


| Sequence Number 


+ SSS EE ge 


Se A A E ES + 
Class | 
nei + 
STATIC-DEF | 
PATTERN | 
SSS SSS A E + 


This field is used to identify a distinct flow between two IPsec 


peers and it changes rarely; 


STAT 


ESP Sequence Number 


IC-DEF. 


therefore, 


it is classified as 


The ESP Sequence Number will be incremented by one for each packet 


sent 


A.7. IPv6 Extension Header Fields 


Optio 


+ mes min 


Next He 


Routing 
Hop-by-hop 
Destination 
ns 

Routing 
Hop-by-hop 
Destination 


ader 


STATIC-DEF 


STATIC-DEF 
STATIC 
STATIC 


STATIC-DEF 
RACH 
RACH 


4+--------------- + 


This field will have the same value in all packets of a flow and 
is therefore classified as STATIC-DEF. 
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Ext Hdr Len 


For the Routing header, it is expected that the length will remain 
constant for the duration of the flow, and that a change in the 
length should be classified as a new flow by the ROHC compressor. 
For Hop-by-hop and Destination options headers, the length is 
expected to remain static, but can be updated by an IR packet. 


Options 


For the Routing header, it is expected that the option content 
will remain constant for the duration of the flow, and that a 
change in the routing information should be classified as a new 
flow by the ROHC compressor. For Hop-by-hop and Destination 
options headers, the options are expected to remain static, but 
can be updated by an IR packet. 


A.8 GRE Header Fields 
+-------------------- +--------------- + 
| Field | Class 
+-------------------- +--------------- + 
| C flag | STATIC 
| K flag | STATIC | 
| S flag [STATIC | 
| R flag | STATIC-KNOWN | 
| Reserved0, Version | STATIC-KNOWN | 

Protocol STATIC-DEF 
Checksum IRREGULAR 
| Reserved | STATIC-KNOWN | 
| Sequence Number | PATTERN | 
| Key | STATIC-DEF | 
+-------------------- +--------------- + 
Flags 


The four flag bits are not expected to change for the duration of 
the flow, and the R flag is expected to always be set to zero. 


Reserved0, Version 


Both of these fields are expected to be set to zero for the 
duration of any flow. 


Protocol 


This field will have the same value in all packets of a flow and 
is therefore classified as STATIC-DEF. 


Pelletier & Sandlund Standards Track [Page 118] 


RFC 5225 ROHCv2 Profiles April 2008 


Checksum 


When the checksum field is present, it is expected to behave 
unpredictably. 


Reserved 
When present, this field is expected to be set to zero. 
Sequence Number 


when present, the Sequence Number increases by one for each 
packet. 


Key 


When present, the Key field is used to define the flow and does 
not change. 


A.9. MINE Header Fields 


+--------------------- +---------------- + 
| Field | Class | 
+--------------------- +---------------- + 
| Protocol | STATIC-DEF | 
| S bit | STATIC-DEF | 
| Reserved | STATIC-KNOW | 

Checksum INFERRED 

Source Address STATIC-DEF 
| Destination Address | STATIC-DEF | 
+--------------------- +---------------- + 
Protocol 

This field will have the same value in all packets of a flow and 

is therefore classified as STATIC-DEF. 
S bit 

The S bit is not expected to change during a flow. 
Reserved 


The reserved field is expected to be set to zero. 
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Checksum 


The header checksum protects individual routing hops from 
processing a corrupted header. Since all fields of this header 
are compressed away, there is no need to include this checksum in 
compressed packets and it can be regenerated at the decompressor 
side. 


Source and Destination Addresses 


These fields can be used to define the flow and are not expected 
to change. 


A.10. AH Header Fields 


+--------------------- +---------------- + 

| Field | Class | 

+--------------------- +---------------- + 

| Next Header | STATIC-DEF 

| Payload Length | STATIC | 

| Reserved | STATIC-KNOWN | 
SPI STATIC-DEF 
Sequence Number PATTERN 

| ICV | IRREGULAR | 

+--------------------- +---------------- + 


Next Header 


This field will have the same value in all packets of a flow and 
is therefore classified as STATIC-DEF. 


Payload Length 


It is expected that the length of the header is constant for the 
duration of the flow. 


Reserved 
The value of this field will be set to zero. 
SPI 
This field is used to identify a specific flow and only changes 


when the sequence number wraps around, and is therefore classified 
as STATIC-DEF. 
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Sequence Number 


The Sequence Number will be incremented by one for each packet 
sent. 


ICV 


The ICV is expected to behave unpredictably and is therefore 
classified as IRREGULAR. 


Appendix B. Compressor Implementation Guidelines 


This section describes some guiding principles for implementing a 
ROHCv2 compressor with focus on how to efficiently select appropriate 
packet formats. The text in this appendix should be considered 
guidelines, it does not define any normative requirement on how 
ROHCv2 profiles are implemented. 


B.1. Reference Management 


The compressor usually maintains a sliding window of reference 
headers, which contains as many references as needed for the 
optimistic approach. Each reference contains a description of which 
changes occurred in the flow between two consecutive headers in the 
flow, and a new reference is inserted into the window each time a 
packet is compressed by this context. A reference may for example be 
implemented as a stored copy of the uncompressed header being 
represented. When the compressor is confident that a specific 
reference is no longer used by the decompressor (for example by using 
the optimistic approach or feedback received), the reference is 
removed from the sliding window. 


B.2. Window-based LSB Encoding (W-LSB) 


Section 5.1.1 describes how the optimistic approach impacts the 
packet format selection for the compressor. Exactly how the 
compressor selects a packet format is up to the implementation to 
decide, but the following is an example of how this process can be 
performed for lsb-encoded fields through the use of Window-based LSB 
encoding (W-LSB). 


With W-LSB encoding, the compressor uses a number of references (a 
window) from its context. What references to use is determined by 
its optimistic approach. The compressor extracts the value of the 
field to be W-LSB encoded from each reference in the window, and 
finds the maximum and minimum values. Once it determines these 
values, the compressor uses the assumption that the decompressor has 
a value for this field within the range given by these boundaries 
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(inclusively) as its reference. The compressor can then select a 
number of LSBs from the value to be compressed, so that the LSBs can 
be decompressed regardless of whether the decompressor uses the 
minimum value, the maximum value or any other value in the range of 
possible references. 


B.3. W-LSB Encoding and Timer-based Compression 


Section 6.6.9 defines decompressor behavior for timer-based RTP 
timestamp compression. This section gives guidelines on how the 
compressor should determine the number of LSB bits it should send for 
the timestamp field. When using timer-based compression, this number 
depends on the sum of the jitter before the compressor and the jitter 
between the compressor and decompressor. 


The jitter before the compressor can be estimated using the following 
computation: 


Max_Jitter_BC = 
max {| (T_n - T_j) - ((an-a 3) / time_stride) |, 
for all headers j in the sliding window} 


where (T_n - T 35) is the difference in the timestamp between the 
currently compressed header and a reference header and (a_n - a_j) is 
the difference in arrival time between those same two headers. 


In addition to this, the compressor needs to estimate an upper bound 
for the jitter between the compressor and decompressor 

(Max Jitter CD). This information may for example come from lower 
layers. 


A compressor implementation can determine whether the difference in 
clock resolution between the compressor and decompressor induces an 
error when performing integer arithmetics; it can then treat this 
error as additional jitter. 


After obtaining estimates for the jitters, the number of bits needed 
to transmit is obtained using the following calculation: 


ceiling(log2 (2 * (Max_Jitter_BC + Max Jitter CD + 2) + 1)) 


This number is then used to select a packet format that contains at 
least this many scaled timestamp bits. 
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